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.  PREFACE 


{ 


A 


The  real-time  technology  program  at  the  Center  for  Software 
Engineering,  CECOM,  is  based  on  recognized  problems  encountered  in  the 
development  of  embedded  real-time  Ada  systems.  The  first  step  in  the 
program  was  to  define  this  set  of  root  problems.  The  approach  was  to  conduct 
interviews  with  both  program  managers  and  system  developers  working  on 
Ada  real-time  applications  for  the  Army  and  then  to  analyze,  categorize,  and 
enter  into  an  dat^sg^e  resulting  set  of  issues.  ^ 


This  document  includes  the  two  technical  reports  that  resulted  from  the 
effort  to  define  this  set  of  problems.  The  authors  were  chosen  because  of  their 
proven  expertise  in  real-time  development  with  Ada.  They  could  enrich  the 
results  of  the  interview  process  with  their  own  experience  in  this  area. 


C 


The  first  report  is  entitled  ^'Software  Engineering  Issues  on  Ada 
Technology  Insertion  for  Real-Time  Embedded  Systems**:^  LabTek 
Corporation,  the  author,  had  proven  expertise  in  embedded  system  design 
utilizing  Motorola  MC680X0-  based  processors. 

^  The  second  report  is  entitled^Software  EMineering  Problems  Using  Ada 
in  Computers  Integral  to  Weapons  Systems.*^  Its  author,  Sonicraft,  had 
expertise  in  evaluating  system  requirements  and  in  performing  high-level 

system  design  utilizing  the  Intel  80X86  family  of  processors.  ^  ^  p  ^ 
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EXECUTIVE  SUMMARY 

This  report  is  the  result  of  a  study  to  identify  and  classify  the  problems  associated  with  the 
current  use  of  the  Ada  programming  language,  particularly  in  real-time  embedded 
applications.  The  term  "Ada  technology"  which  appears  in  the  report  title  refers  to 
currently  available  Ada  compilation  systems,  tools  and  associated  methodologies.  The 
conclusions  of  the  study  indicate  that  some  of  the  prominent  problems  are  due  to  the 
immaturity  of  the  commercially  available  Ada  compilation  systems  which  includes  the 
runtime  environments.  It  is  believed  that  these  compiler  problems  will  be  nearly  eliminated 
by  the  compiler  vendors  within  five  years,  provided  that  the  demand  for  solutions  to  these 
real-time  problems  is  sustained.  Other  problems  include  the  substantial  resources  needed 
to  develop  Ada  software  and  the  lack  of  Ada  debugging  tools.  In  addition,  the  inexperience 
with  Ada  imposes  many  management  concerns.  While  ctying  to  maintain  cost  and  schedule 
objectives,  management  must  train  its  personnel  and  deal  with  the  unknowns  of  the  chosen 
Ada  compilation  system. 
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1.  Overview 

The  progranuning  language  Ada,  was  developed  to  reduce  the  life  cycle  development  cost 
of  mission  critical  real-time  embedded  systems.  Most  of  these  systems  are  characterized  by 
long  development  times  and  long  lives  with  continual  changes  and  expansions  in  their 
environment  The  ability  to  evolve  and  grow  is  important  Development  efforts  are  further 
complicated  by  the  Ugh  reliability  required  for  these  systems.  Building  reliable  software  is 
a  major  issue  when  failures  could  result  in  loss  of  life  and  tremendous  economic  costs. 
Deterministic  behavior  is  an  essential  criteria  of  an  embedded  real-time  system  because  a 
random,  non-repeatabie  failure  may  lead  to  a  catastrophic  life  threatening  situation.  Here, 
the  stability  of  tne  target  system  is  of  utmost  importance. 

Typically,  embedded  ^tems  software  is  developed  on  large  minicomputers  with  a  variew  of 
periphery  such  as  di^  drives,  printers,  and  a  large  number  of  interactive  terminals.  This 
^tem  is  often  referred  to  as  the  Tiost"  computer.  The  host  computer  used  for  softw^e 
development  is  usually  different  hrom  the  embedded  computer  that  will  run  the  application 
progrias.  The  computer  hardware  and  operating  system  on  which  the  applicatipn  prograi^ 
executes  is  called  the  target  system.  The  nost’s  operating  system,  such  as  VMS  or  UNIX 
supports  the  tools  needed  to  create  the  application  prograi^  The  tools  include  editors  for 
writing  the  programs,  compilers  and  assemblers  for  translating  the  modules  into  executable 
code,  and  utilities  for  preparing  the  application  for  execution  (unong  others). 

There  are  a  number  of  aspects  of  the  Ada  Ismguage  that  make  it  different  from  languages 
that  have  been  used  to  implement  real-time  systems.  Perh^  the  most  significant 
difference,  from  a  real-time  software  point  of  view,  is  the  interaction  between  the  language 
features  and  the  execution  time  support  for  those  features.  The  most  obvious  feature  that 
illustrates  this  point  is  the  Ada  task.  Tasking  has  alwa^  been  used  in  real-time  systems, 
however  it  is  normally  provided  by  a  separate  ^exccutr.'e''^  that  manages  the  tasks  as  separate 
cooperating  programs.  In  Ada,  tasks  are  part  of  the  language,  and  therefore  every  Ada 
implementanon  must  support  taking,  and  there  is  a  high  degree  of  integration  between 
language  features  and  the  tasking  model  This  precludes  using  a  typical  independently 
developed  executive  to  provide  the  tasking  services.  This  tij^t  coupling  between  the 
language  and  the  routines  that  are  necessaiv  to  support  the  nmtune  execution  has  a  major 
impact  on  the  flexibility  of  Ada  applications.  An  Ada  runtime  (often  called  runtime 
support)  is  the  set  of  procedures  or  functions  required  to  support  the  code  generated  from  a 
compilation.  It  is  this  runtime  that  is  now  provided  by  compiler  vendors  that  was  previously 
developed  by  application  builders. 

The  use  of  Ada  for  real-time  embedded  systems  is  exposing  a  number  of  serious  software 
engineering  issues.  It  is  apparent  from  interviewing  program  managers,  software  managers, 
sonware  engineers,  and  application  engineers  that  m^  are  encountering  similar  types  of 
problems  when  ti>^  to  s^ly  the  current  commercially  available  Ada  technology.  The 


^VMS  is  a  trademark  of  Digital  Equipmeiit  Corporatkm. 
^UNDC  is  a  trademark  of  AT&T  Bell  Laboratories,  Inc. 
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purpose  of  this  report  is  to  identify  the  problems  encountered  by  real-time  embedded 
applications  using  Ada  technology  and  to  classify  them. 

2.  Approach 

The  approach  used  to  obtain  the  information  in  this  report  was  to; 

1.  identify  sources  of  information  related  to  problems  with  the  use  of  Ada, 

2.  contact  those  sources  of  input  and  obtain  specific  information  on  Ada  issues, 

3.  verify  the  input  obtained  with  an  additional  source,  where  necessary, 

4.  organize  and  categorize  that  information  into  common  areas,  and 

5.  analyze  the  resultant  material  for  direction  in  the  resolution  of  these  issues. 

Three  primary  sources  of  input  were  identified.  The  most  important  source  of  information 
was  through  interviews.  Interviews  were  conducted  with  program  managers,  software 
managers  and  ^>piication  engineers  by  LabTek  personnel  to  mscuss  the  problems  that  were 
encountered.  Ine  reponed  problems  were  analyze^  by  LabTek  personnel  and  verified  by 
an  additional  source  (Le.  compiler  vendors,  Ada  Joint  Program  Croce  (AJPO),  etc.)  where 
necessary.  The  Ada  Runtime  Environmem  Working  Group  (ARTcWG)  and  Special 
Interest  Group  on  Ada  (SIGAda)  meetings  served  as  a  second  source  of  information. 
These  meetings  and  conferences  were  attended  bv  LabTek  personnel  with  special  attention 
given  to  talks  concerning  Ada  and  real-time  appucations.  dompiler  vendor  products,  tools, 
and  methodologies  that  support  them  were  also  reviewed  at  these  meetings.  The  third 
source  was  the  current  Ada  and  software  engineering  related  literature. 

2.1  Interviews 

LabTek  Corp.  has  established  a  wide  customer  base  and  has  been  involved  with  providing 
consulting  services  for  many  customers  on  their  Ada  applications.  In  addition  to  conducting 
the  following  interviews,  LabTek  has  included  its  own  experiences  in  identifying  the 
problems.  Most  of  the  projects  interviewed  below  were  still  under  development  at  the  time 
of  the  interview. 

2.1.1  Program  Manager  Interviews 

*  Advanced  Field  Artillery  Tactical  Data  Systems  (AFATDS),  Fort  Monmouth,  NJ, 
CECOM 

*  Army  Secure  Operating  System  (ASOS),  Fort  Monmouth,  NJ,  CECOM 

■  Improved  HELLFIRE  DIGITAL  AUTOPILOT  (DAP),  Redstone  Arsenal, 
Alabama,  MICOM 

*  Howitzer  Improvement  Program  (HIP),  Picatinny  Arsenal,  AMCOM 

*  Tank  Improvements  (M60A3),  Picatinny  Arsenal,  NJ,  AMCOM 
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*  Nuclear,  Biological,  &  Qiemical  Reconnaissance  (NBCRS),  Picatinny  Arsenal, 
AMCOM 

*  Sense  and  Destroy  Armor  (SADARM),  Picatinny  Arsenal,  NJ,  AMCOM 

*  Single  Channel  Objective  Tactical  Terminal  (SCOTT),  Fort  Monmouth,  NJ, 
CECOM 

2.12  Private  Industry  Interviews 

*  Advanced  Field  Artillery  Tactical  Data  Systems  (AFATDS),  Magnavox  Electronics 
Systems  Co.,  Fort  Wayne,  Indiana 

*  Bradley  Fighting  Vehicle  (BEDS),  FMC/Digital  Turret  Distribution  Box,  San  Jose, 


•  Bradley  Fighting  Vehicle  (DTDB),  FMC/Digital  Turret  Distribution  Box,  San  Jose, 


*  Bradley  Fighting  Vehicle,  GE/Digital  Electronics  Control  Assembly,  Pittsfield,  MA 

*  F4-J  Weapon  System  Trainer,  Science  Applications  International  Corp.  (SAIC), 
Huntsville,  Alabama 

*  Lightweight  Helicopter  (LHX),  United  Technologies  Sikorsky  Aircraft,  Stratford. 
CT 

*  Tank  Improvements  (M60A3),  Computing  Devices  COn  Ottowa,  Canada 

*  Nuclear,  Biological,  &,  Chemical  Reconnaissance  (NBCRS),  TRW,  Redondo 
Beach,  CA 

12  ARTEWG  and  SIGAda  Mcedogs 

The  ARTEWG  is  a  group  sponsored  by  SIGAda  whose  purpose  is  to  address  the  problems 
encountered  in  runtime  environments.  Some  of  these  problems  are  occurring  beduise  Ada 
compiler  implementors  are  making  executive  function  dedsioos  that  application  developers 
previously  made  on  their  own  when  they  built  their  own  executives.  The  current 
implementations  are  not  satisfying  all  embedded  application  needs.  [4]  It  is  ARTEWG’s 
re^nsibility  to  establish  conventions,  criteria,  and  guidelines  tor  Ada  runtime 
environments.  This  will  facilitate  reu^ilify  and  transportabiUfy  of  Ada  program 
components,  improve  the  performance  of  those  components,  and  provide  a  framework 
whitm  can  be  used  to  evaluate  Ada  runtime  systems.  Tom  Griest  of  LaoTek  is  an  ARTEWG 
principal  and  the  leader  of  subgroup  one,  the  Implementation  Dependencies  Subgroup.  As 
such,  he  participates  in  the  ARTbWG  meetings  and  provides  uqiut  into  its  documents. 
These  documents  were  examined  for  their  relevance  to  t^  report 

The  SIGAda  meetings  are  held  four  times  a  year  (three  times  in  the  U.S.  and  once  in 
Europe)  and  LabTek  personnel  attend  thoe  comerences  with  special  attention  paid  to  talks 
by  users  concerning  real'time  embedded  appUcations  and  methodologies.  Vendor  products 
are  also  examined. 


A  -3r 


Ada  Technology  Issues 


23  Literature 

The  Ada  issues  database  was  obtained  from  the  ARPANET.  This  database  is  an 
accumulation  of  problems  and  questions  on  Ada  and  coined  ”Ada  issues”.  This  database 
was  scanned  for  the  real-time  relevant  issues. 

A  literamre  search  was  also  conducted.  Sources  included  papers  from  the  ARTEWG, 
ACM  Ada  Letters,  ACM  SIGPLAN  Notices,  ACM  Software  Engineering  Notes,  EEEE 
Software,  EEEE  Transactions  on  Software  Engineering,  Defense  Science  &  Elearonics  and 
Computer  Language  magazine.  All  relevant  articles  were  reviewed  and  evaluated. 

14  Criteria  for  Issue  Deflnition 

To  determine  the  validity  of  a  reported  issue  two  ^estions  were  asked:  1)  Is  the  problem 
the  result  of  the  improper  use  of  Ada?,  and  2)  Is  the  problem  really  a  symptom  of  an 
underlying  issue?  If  the  answer  to  question  one  was  afSrmative  the  problem  was  rejeaed. 
If  the  answer  to  question  two  was  amrmadve  the  problem  was  restated  to  indicate  the  true 
problem.  In  addition,  LabTek  obtained  multiple  sources  reporting  the  same  problem.  This 
can  be  seen  in  section  4,  the  Issue  Vs.  Source  Matrix. 

3.  Ada  Technology  Issues  In  Real-Time  Embedded  Systems 

Developing  software  for  real-time  embedded  applications  requires  diverse  skills  and 
approaches  for  problem  recognition  and  solution.  The  software  implementation  of  a 
problem  solution,  however,  can  be  approached  by  using  a  set  of  techniques  that  are 
application-independent.  These  techniques  form  the  basis  of  a  software  engineering 
methodolo^.  Software  engineering  is  modeled  on  the  time-proven  techniques,  methods, 
and  controls  associated  with  hardware  developmenL  Although  fundamental  difterences  do 
exist  between  hardv^e  and  software,  the  concepts  associated  with  plaiming,  development, 
review,  and  management  control  are  similar  for  both  system  elements.  The  key  objectives 
of  software  engineering  are  1)  a  well-defined  methodology  that  addresses  a  software 
life-cycle  of  planning,  development,  and  maintenance,  2)  an  established  set  of  software 
components  that  documents  each  step  in  the  life-cycle  and  shows  traceability  from  step  to 
step,  and  3)  a  set  of  predictable  milestones  that  can  be  reviewed  at  re^ar  intervals 
throughout  the  software  life-cyde.  [9] 

Ada  technology  is  used  to  produce  the  real-dme  software  in  an  embedded  system. 
Real-time  software  measures,  analyzes  and  controls  real  world  events  as  thj^  occur.  A 
real-dme  system  must  respond  withm  strict  time  constraints.  Note  that  this  is  different  from 
"interactive"  or  "dme-sharai"  where  the  response  dme  can  normally  be  exceeded  without 
disastrous  results.  Ada  technology  consists  of  the  compilation  ^tems,  tools, 
methodologies,  prindpies  and  techniques  that  are  employed  to  develop  and  maintain  Ada 
software. 

The  problems  encountered  when  using  Ada  technology  for  real-dme  embedded 
applicadons  are  enumerated  here.  The  problems  are  divided  into  difierent  dassificadons. 
In  some  case^  an  issue  may  be  applicable  to  more  than  one  classification.  When  this  has 
occurred  the  issue  has  been  placed  in  the  classification  where  it  has  the  most  sign^cance. 
A  tree  of  the  different  dassificatioos  can  be  seen  in  Figure  1.  The  tree  provides  the 
structure  for  section  3  of  this  report 
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To  provide  easy  extraction  of  problem  definition  from  background  and  support,  each 
problem  is  detailed  with  these  four  subheadings: 

1. )  Issue/Problem  Definition  -  The  nssue/Problem  Definition"  subheading  provides  a 
conclusive  problem  definition  (what  is  at  issue).  If  the  problem  or  issue  manifests 
itself  differently  than  the  analyzed  and  defined  (conclusive)  problem,  then  a  few 
sentences  restating  problem  "symptoms"  may  be  included.  If  there  isn’t  any  problem 
associated  with  a  particular  classification  it  will  be  so  stated.  In  these  cases,  the 
classification  was  included  for  completeness  to  this  report. 

2. )  Background  -  The  "Background"  subheading  provides  a  framework  for 
understanding  both  the  general  nature  of  the  problem  and  the  analysis  that  follows 
this  part.  Brief  observations  about  the  problem  or  issue  categorization  and  a  few 
sentence  discussion  of  the  source(s)  of  information  about  me  problem  will  be 
included  in  this  subheading,  as  well  as  any  relevant  definitions. 

3. )  Analysis  Sc.  Support  -  The  "Analysis  Sc.  Support*  subheading  will  contain  detailed 
observations  about  the  substance  of  the  issue  as  well  as  any  assunrotions  made  by 

'  LabTek  during  the  analysis.  Also  included  in  this  subheading  is  any  d^ta  or  rationale 
that  supports  the  findings  and  a  summary  of  the  conclusions  about  the  problem.  If 
available,  any  related  or  connected  problems  will  be  mentioned  as  well  as  zm  specific 
causes,  conditions,  or  constraints  under  which  the  problem  manifests  itself.  It  mere  is 
other  specific  criteria  which  may  be  used  by  the  reader  to  evaluate  the  validity  of  the 
conclusions,  it  will  be  provided. 

4. )  Problem  Resolution  -  The  "Problem  Resolution"  subheading  may  provide 
construaive  and  reasonable  recommendations  for  problem  resolution  in  the  form  of 
plans,  approaches,  methods,  work>arounds,  engineering  techniques,  etc..  It  may  detail 
associated  conditions  or  constraints  affecting  a  reasonable  resolution.  V^en  a 
problem  resolution  is  provided  an  associated  lime  frame  will  be  given.  Within  the 
context  of  this  report,  a  "short-term"  problem  resolution  is  one  that  can  be 
implemented  within  one  to  two  years,  and  a  "long-term"  problem  resolution  is  one 
that  can  be  implemented  in  two  to  ten  years. 
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3.1  Compilation  Systems 

An  Ada  corroilation  system  translates  an  Ada  source  program  into  its  machine  code 
equivalent.  There  are  many  aspects  that  make  Ada  oifferem  from  other  high-order 
languages  (HOLs).  The  combination  of  features  to  support  parallel  execution,  exception 
handling,  information  hiding,  strong  typing,  etc,  make  it  different.  However,  with  respect  to 
real-time  embedded  applications,  the  most  significant  difference  is  the  inclusion  of  a  tasking 
model  and  other  feamres  that  were  previously  not  pan  of  other  HOLs,  but  of  a  separate 
executive.  Now,  the  Ada  compiladon  ^tem  supplies  the  code  that  was  previously  provided 
by  a  separate  executive.  That  is,  Ada  compilation  systems  provide  an  extensive  "runtime " 
which  other  traditional  compilers  did  not  The  runtime  (also  called  runtime  support)  is  the 
set  of  procedures  or  functions  required  to  support  the  code  generated  from  a  compilation 
(i.e.  entry  call  in  a  task,  exception  raising,  abon  processing,  stnng  catenation,  etc.). 

The  following  sections  discuss  the  problems  with  the  currently  available  Ada  compilation 
systems  in  detail. 

3.1.1  JRuntime  Environments 

Issue/Problem  Definition:  In  other  languages,  application  writers  were  accustomed  to 
tailoring  their  executives  so  that  they  were  extremely  efficient  for  a  particular  application. 
.Now,  with  the  advent  of  Ada,  the  compiler  implementors  have  control  of  the  runtime 
environment,  and  that  tailoring  ability  has  been  lost  to  a  great  extent  in  the  current 
generation  of  Ada  products. 

Background:  Applications  are  dependent  on  the  runtime  to  provide  an  efficient 
implementation  to  support  system  services  (Le.  tasking,  storage  management,  exception 
handling,  etc.).  A  runtime  environment  (RTE)  includes  all  of  the  runtime  support  routines, 
the  conventions  between  the  runtime  routines  and  the  compiler,  and  the  underlying  virtual 
machine  of  the  target  computer.  Virtual  is  used  in  the  sense  that  is  may  be  a  machine  with 
layered  software  (a  host  operating  system).  An  RTE  does  not  include  toe  application  itself, 
but  includes  everything  the  application  can  interaa  with.  Each  layer  has  a  protocol 
between  it  and  the  layer  underneath  it  for  interfacing.  In  the  event  that  there  isn’t  any 
operating  system  layer,  the  runtime  includes  those  low-^el  functions  foimd  in  an  operating 
system.  See  Figure  Z 
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Figure  2.  Ada  Runtime  Environment  (RTE) 


This  information  was  supplied  by  the  following  sources:  Project  Interviews,  ARTEWG  & 
SIGAda  Meetings,  Current  Softwve  Engineering  Literature,  and  LabTek  Experience. 

Anafysis  Support:  The  complexity  of  the  interface  between  the  runtime  and  the  generated 
code  from  the  Ada  compiler  is  substantial  The  difficulty  is  in  the  lack  of  intimate 
knowledge  of  bow  the  runtime  links  to  the  compiler  generated  code.  Furthermore,  the 
runtime  must  meet  a  rigorous  set  of  tests  to  insure  that  it  complies  with  the  Ada  standard. 
The  nmtime  environment  of  the  Ada  compilation  system  must  mways  comply  with  the  rules 
of  the  Ada  language  as  defined  by  the  Reference  Manual  for  the  Ada  Programming 
Language.  These  are  major  changes  from  the  way  other  runtimes  were  developed  in  the 
past. 

In  summary,  there  is  always  a  reluctance  on  the  part  of  a  programmer  to  give  up  control. 
The  problem  will  become  less  severe  as  the  compiler  vendors  provide  greater  flexibility  in 
their  runtimes  and  as  software  designers  leam  to  take  advantage  of  the  features  that  are 
provided. 

Problem  Resolution:  (Short  Term)  A  list  should  be  generated  of  what  Ada  runtime  features 
are  most  needed  by  real>time  embedded  applications.  This  list  could  be  provided  to 
compiler  implementors,  and  later  used  as  a  checklist  by  people  evaluating  compuers. 

(Long  Term)  These  features,  if  provided  in  a  configurable  runtime,  could  solve  many  of  the 
real'Ume  issues. 
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3.1.1.1  Configurability 


Badcgroumi:  Software  is  said  to  be  "configurable"  if  the  user  can  select  various  options 
when  building  the  application  software.  In  the  case  of  the  Ada  runtime  environment,  a 
configurable  component  might  be  the  type  of  scheduler  used  for  the  tasking  algorithm. 


This  information  was  supplied  by  the  following  sources:  Project  Interviews,  ARTEWG  & 
SIGAda  Meetings,  Current  Softu^e  Engineering  Literature,  and  LabTek  Experience. 

Anafysis  &  Support:  There  is  a  trend  developins  towards  providing  "intelligent"  loading 
capabilities.  An  intelligent  loader  will  only  load  those  features  of  the  runtime  that  are 
required  the  applicanon.  That  is,  there  is  no  point  in  loading  the  code  to  support  tasking, 
if  tasking  is  not  used  by  the  applicadoiL  In  a  sense,  this  could  be  considered  a  configuration 
of  the  runtime.  However,  runtime  configurability,  in  the  context  of  this  report,  woiud  allow 
an  application  engineer  to  specify  such  features  as:  the  tasking  algorithm  used  by  the 
scheauler,  or  the  memo^  management  technique  used,  (among  omers).  In  conducting  the 
various  interviews,  intelligent  loading  capabilities  were  appearing.  However,  when  a  special 
runtime  configuration  was  needed  ^ch  as  a  particuiar  type  of  scheduler),  the  contractor 
had  to  rely  on  the  compiler  vendor  to  perform  me  configuration. 

In  summary,  this  will  be  a  more  severe  problem  for  some  applications  than  others.  A  group 
of  engineers  trying  to  write  an  operating  system  in  Ada  will  have  extreme  difficulty  if  not 
able  to  control  the  tasking  aspects  of  the  runtime.  Con^iler  vendors  are  aware  that  users 
need  configurable  runtimes  due  to.  the  requests  they  receive  to  tailor  them. 

Some  people  doubt  whether  complete  "configurabilify"  is  even  possible  for  real-time 
embedded  systems  and  feel  that  some  "hand  tumng"  will  always  be  necessary.  The  general 
belief  is  that  it  is  possible  to  achieve  the  necessafy  performance  and  adaptation 
requirements  for  most  systems  if  sufficient  configurability  is  provided. 

Problem  Resolution: 

(Short  Term) 

1. )  The  ability  for  usen  to  provide  substitutes  for  any  vendor  supplied  runtime 
routines  is  necessary.  This  is  telieved  to  be  the  only  way  that  distributed  systems  can 
be  developed,  as  well  as  many  non-standard  single-processor  implementations. 

2. )  The  vendors  must  supply  sufficient  interface  information  on  their  runtime  routines 
to  allow  customers  to  make  these  substitutions. 

3. )  Schedules  must  include  time  for  this  customization  process. 

(Long  Term) 

4. )  Vendors  should  be  encour^ed  to  provide  configurability  that  has  a  high  degree  of 
autoniation.  This  configuration  process  must  be  able  to  be  performed  ^  the 
application  engineers,  since  relying  on  the  compiler  vendor  onen  results  in  an 
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unacceptable  delay.  An  .bilijy  to  selectively  choose  from  among  several  versions  of 
the  runtime  routines  to  buiid  a  runtime  environment  that  is  customized  for  a 
particular  application  is  what  is  needed.  In  this  way,  the  optimal  tasking  algorithm 
(dynamic  priorities,  run-dll-blocked,  round-robin,  time  slicing,  etc.)  can  be  chosen. 
Menu  oriented  systems  that  verify  compatibility  are  probably  best.  Provisions  must 
be  made  with  the  configuration  management  mechanism  to  allow  determining  the 
components  of  a  generated  runtime. 

5.)  Support  tools  to  make  the  configuration  process  semi-automatic  and  reliable. 

Issue/Problem  Definition:  A  configurable  math  library  is  required  by  many  projects,  and  is 
not  provided.  Along  with  the  library,  a  set  of  tests  should  be  provided  to  verify  the  accuracy 
of  the  library  after  changes  have  been  made. 

Background:  Accuracy  and  timing  vary  greatly  from  application  to  application.  For 
example,  some  projects  use  a  look-up  ^le  for  speed  in  computing  transcendental 
functions. 

This  information  was  supplied  by  the  followii^  sources:  Projea  Interviews,  ARTEWG  Sc. 
SIGAda  Meetings,  Current  Software  Engineering  Literature,  and  LabTek  Experience. 

Analysis  &  Support:  A  mechanism  is  needed  which  allows  users  to  modify  the  standard  math 
library  provided  by  vendors.  (Note:  the  Ada  language  does  not  include  facilities  for 
transcendental  math  functions.)  In  talking  with  the  various  engineeis  it  was  pointed  out  that 
many  projects  have  their  own  math  library. 

In  summary,  many  applications  custom  code  their  own  math  library.  This  practice  should 
be  changed. 

Problem  Resolution:  (Short  Term)  Ada  math  libraries  are  being  developed  and  placed  into 
the  public  domain.  Ifrovisions  must  be  made  for  making  application  builders  aware  of  this 
resource. 

3.1.12  Execution  Performance 

Issue/Problem  Definition:  The  quality  of  the  compiler  generated  code  is  often  inadequate 
for  real-time  embraded  systems. 

Background:  Efficiency  is  used  in  this  context  to  mean  the  combined  performance  of  the 
compiler  generated  code  and  the  runtime.  It  is  a  relative  term,  comparing  the  processing 
rate  of  the  high  level  code  to  the  hypothetical  optimal  assembly  language. 

Tuning  is  a  critical  constraint  in  a  real-time  application.  The  sampUng  of  data,  a  calculation 
providmg  input  to  a  feedback  loop,  the  driving  of  servos,  the  handling  of  external  interrupts 
are  some  euunples  of  functions  mat  must  be  performed  in  a  precise  time  intervaL  If  they 
ore  not  performed  in  the  specified  time  interval  the  system  will  not  function  properly.  In  a 
flight  system  this  problem  could  be  manifested  in  a  pilot  receiving  the  wrong  positional 
information  at  a  critical  time.  Although  the  runtime  can  create  short  term  processing 
delays,  the  average  throughput  of  the  computer  is  generally  most  impaaed  by  the 
optimization  of  the  generated  code. 
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This  information  was  supplied  by  the  following  sources:  Project  Interviews,  ARTEWG 
SIGAda  Meetings,  Current  Softwve  Engineering  Literamre,  and  LabTek  Experience. 

Analysis  &  Support:  Which  Ada  features  are  most  costly  to  use  is  a  function  of  each 
implementation.  Examples  of  critical  areas  where  the  runtime  code  has  to  be  efficient  are: 

*  The  Ada  rendezvous  (task  signalling  and  communication).  In  general,  the  task 
management  function  tends  to  have  the  greatest  amount  of  overhead. 

*  Dynamic  storage  management 

*  Exception  handling.  Often  the  problem  is  avoiding  overhead  in  the  absence  of 
exceptions.  Since  every  subprogram  invocation  involves  a  new  exception  scope,  care 
must  be  taken  to  reduce  the  overhead  associated  with  maintaining  the  current 
appropriate  exception  handler.  Tradeoffs  can  be  made  between  exception  handling 
that  propagate  exceptions  quickly,  or  those  that  do  not  impose  delays  during  norm^ 
(non*exception)  processing  Most  exceptions  occur  only  when  severe  problems 
(hardware  or  design)  exist,  provided  the  exception  mechanism  isn’t  mistised. 
Therefore  the  penalty  for  slow  exception  handling  is  usually  acceptable  if 
non<exception  processing  can  execute  without  additional  overhead. 

*  Constraint  checking  is  another  candidate,  depending  on  the  implementation.  When 
constraint  checking  becomes  too  severe,  most  implementations  ^ve  a  mechanism  to 
disable  the  constraint  checks.  Ada  provides  a  standard  technique  for  this  in  the 
SUPPRESSpragma. 

*  Support  for  interrupts. 

*  Procedure  call  overhead. 

*  Stack  overflow  check. 

*  Array  referencing. 

In  summary,  eighty  one  percent  of  the  projects  interviewed  reponed  that  the  quality  of  the 
generated  code  was  a  major  problem  for  their  real-time  embedded  plication. 

Problem  Resolution:  (Long  Term)  Vendon  should  be  encouraged  to  provide  a  high  degree 
of  optimization.  This  encouragement  can  take  the  form  of  a  policy  to  interpret  the 
language  standard  so  as  to  peimit  optimizations  where  they  are  currently  lirnited  by 
language  rules.  Osmpilers  must  also  be  improved  to  take  advantage  of  the  interaction  of 
the  suppress  pragma  and  optimizatioiL  Tl^  is,  the  rules  requiring  the  proper  point  of 
raising  exceptions  restrict  some  optimizations.  If  the  checks  are  suppressed  by  a  pragma, 
these  additional  optimizations  can  take  place. 

Another  solution  might  be  to  subset  use  of  language  features  and  optimize  for  that  subset 
3.1.U  Evaluation 

Issue/Problem  Definition:  It  is  difficult  to  evaluate  Ada  runtime  environments  for  suitability 
in  an  application. 
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Background:  Ev^uation  is  the  ability  to  determine  whether  or  not  the  runtime  environment 
under  consideration  will  be  adequate  for  a  particular  application. 

This  information  was  supplied  by  the  following  sources:  Project  Interviews,  ARTEWG  & 
SIGAda  Meetings. 

An^sis  Support:  Often  the  compiler  user's  is  the  only  material  available  to  lend 

insist  into  the  intricacies  of  the  compiler.  Frequently  it  is  inadequate  for  detailed 
evaluation. 

An  area  where  this  is  especially  true  is  in  measuring  the  dynamic  memory  usage.  One  of 
the  requirements  the  US  i^my  places  on  its  contractors  is  that  50%  of  the  total  memory  be 
reserve  for  expansion.  Since  Ada  allocates  memory  dynamically,  it  is  often  difficult  to 
insure  that  the  worst  case  will  not  use  some  of  the  reserved  50%  of  memory.  It  should  be 
possible  to  compute  the  memt^  usage,  but  the  documentation  for  many  Ada 
implementations  ao  not  provide  sufficient  detail  to  allow  this.  The  use  of  dynmnic  memory 
allocation  caimot  be  avoided  simply  by  elimiitanng  the  use  of  Ada  "allocators’*  in  the  source 
code.  Ada  compilation  systems  use  dynamic  memory  allocadon/deailocation  for  many 
different  operations,  from  allocating  space  on  the  stack  for  subprogram  parameters  to  using 
heap  stors^e  for  manipulation  of  unconstrained  arrays.  Some  tasking  implementations 
require  dynamic  storage  allocation  to  provide  a  separate  task  stack  and  task  control  block 
that  is  allocated  during  task  elaboration.  Therefore  the  user  may  not  know  what  features 
use  dynamic  storage  allocation,  and  it  may  change  in  future  releases  of  the  compiler  system. 

In  summary,  often  the  only  means  of  evaluating  a  compiler  before  purchase  is  through  the 
documentation  and  talking  with  the  compiler  vendor.  The  details  of  how  the  compiler 
implements  the  semantics  of  the  Ada  mdt  must  be  made  known  to  the  application 
developers  in  order  for  them  to  assess  the  impacts  and  tradeofrs  of  using  various  Ada 
langu^e  constructs.  In  general,  very  little  performance  data  is  currently  avsulable  for  Ada 
compilation  systems.  The  best  method  for  detennining  the  critical  tiirune  parameters  and 
storage  usa^e  is  to  analyze  the  code  of  the  runtime  routines.  Ideally  the  vendor  should 
perform  this  analysis  and  provide  the  mfotmadon  to  perspective  customers.  In  practice, 
partially  due  to  the  frequent  changes  made  to  the  runtimes,  the  vendon  do  not  have  this 
information  available.  The  users  are  often  forced  to  purchase  the  compiler  and  source  code 
of  the  runtime  in  order  to  complete  their  evaluation. 

Problem  Resolution:  (Shoa  Term)  Provide  users  with  an  accurate  estimate  of  the  overhead 
an  capabilities  associated  with  the  various  Adz  implementations.  This  would  require  that  a 
study  on  RTEs  be  performed  and  benchmarks  run  for  evaluation.  The  options  available  in 
terms  of  configurability  should  be  included,  with  sizes  listed  and  limitations  imposed  on  the 
application  when  selecting  the  different  configurations.  For  estample,  if  restricted  tasking 
service  is  selected,  the  apfuication  may  be  UmiM  to  usii^  only  simple  rendezvous  capability 
with  no  parameten  supported.  In  pmcular,  the  frmctionality  and  size  of  a  minimal  RTE 
should  be  specified. 

(Long  Term)  Benchmarks  must  be  developed  that  indicate  cridcai  timing  issues  of  Ada 
implementations.  These  are  extremely  difficult  and  time  consuming  to  generate.  For  this 
reason,  it  is  important  that  an  effort  be  supported  to  develop  these  tests  and  to  make  them 
available  to  the  Ada  community.  Ide^y,  each  compiler  that  is  suitable  for  embedded 
processor  use  could  be  evaluated  each  year  after  it  vudates,  and  its  evaluation  placed  in 
the  public  domain.  The  activities  of  the  Ada  Compiler  Evaluation  Capabilir/  (ACEC) 
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effort  and  the  Performance  Issues  Working  Group  (PIWG)  of  SIGAda  should  be 
monitored,  and  if  appropriate,  supponed. 

3.1.1.4  Size 

Issue/Problem  Definition:  Runtime  environment  (RTE)  sizes  are  often  too  large. 

Background:  Size,  in  this  context,  refers  to  the  memory  capacity  required  to  accommodate 
the  runtime. 

This  information  was  supplied  by  the  following  sources:  Project  Interviews,  and  LabTek 
Experience. 

Analysis  &  Support.  Some  applications  may  have  a  total  memory  capacity  of  only  8K  bytes. 
With  the  US  i^jrray  requirement  that  50%  of  total  memory  be  reserved  for  future  expansion, 
this  leaves  4K  bytes  available  for  the  RTE  and  the  application  code.  It  is  currently  not 
technically  possible  to  put  the  RTE  and  the  application  code  in  4K  bytes.  The  smallest 
RTE  encountered  was  ^  bytes,  but  smaller  RTu  are  gradually  appearing. 

A  question  that  many  people  ask  is  "Why  is  the  RTE  so  big?".  The  pressure  on  the  vendors 
has  been  to  validate  earl;^,  rather  than  (mtimize  the  runtimes.  Also,  the  effon  required  to 
produce  small  runtimes  is  significant  The  trend  now  is  to  address  these  issues  and  to 
reduce  the  runtime  size.  The  competition  in  the  Ada  compiler  market  is  forcing  changes  to 
occur. 

Another  concern  relating  to  configurable  runtimes  is  "When  does  one  know  how  big  the 
total  runtime  is  going  to  be?".  The  exact  answer  will  not  be  determined  until  the 
implementation  of  the  application  is  completed.  However,  a  fiuriy  accurate  estimate  is 
needed  before  development  begins  in  order  to  insure  that  the  system  has  sufficient  memory 
capacity.  It  should  be  possible  to  make  a  more  accurate  estimate  when  the  vendors  provide 
documentation  about  their  configurable  runtimes.  Still,  a  significant  amount  of  the 
application  will  need  to  be  known  (e.g.  what  Ada  features  are  used)  prior  to  developing  an 
accurate  estimate. 

In  summary,  sixty>nine  percent  of  the  projects  interviewed  reported  that  the  runtime 
required  a  substantial  percentage  of  the  total  system  memory  thus  severely  limiting  the 
memory  available  for  the  application  code. 

Problem  Resolution'.  (Short  Term)  A  partiai  solution  is  to  use  a  customized  RTE  at  the 
expense  of  not  being  able  to  use  fuu  Ada  (i.e.  text  io,  generics,  tasking  and  dynamic 
allocation).  Restricting  the  use  of  Ada  features  may  also  limit  the  ability  to  reuse  previously 
developed  softwwe. 

It  has  been  suggested  that  for  applications  with  stty  stringent  memory  requirements,  a 
stripped  down  version  of  Ada  be  used  so  that  the  runtiine  is  minimal.  This  cornbined  with  a 
heavy  reliance  on  assembler  code  would  allow  very  small  applications  to  be  written  partially 
in  A^  The  benefit  of  this  approach  is  questionable.  The  a^licadon  would  probably  be 
better  written  entirely  in  assembler  rather  than  a  mixture  of  Ada  and  assembly  language 
when  the  amount  of  Ada  code  is  small,  the  runtime  has  been  virtually  eliminated,  and 
extensive  use  of  assembler  is  made. 
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Issue/Problem  Definition:  Memory  is  critical  constraint  in  many  real-time  embedded 
applications. 

Backffvund: ^  ^though  the  current  trend  is  to  think  that  memory  is  inexpensive  and  be 
adim  if  addidonal  memory  is  needed,  this  is  not  the  case  for  some  embedded  applications. 

This  information  was  supplied  by  the  following  sources:  Project  Interviews,  and  LabTek 
Experience. 

Anafysis  <£  Support:  Following  are  reasons  why  memory  is  a  constraint  in  some  systems: 

*  Use  of  Single  Board  Computers  (SBC).  A  SBC  consists  of  a  processor,  memory, 
and  I/O  ports  on  the  same  board.  The  advantage  to  having  on-board  memory  is  that 
signals  do  not  have  to  be  sent  over  the  backplane,  thus  reducing  the  tima  to  read  and 
write  the  memory.  This  can  significantly  increase  performance. 

*  Packaging.  If  additional  memory  is  required,  it  is  not  always  feasible  to  add  an 
additionid  memory  board.  In  mmiy  cases  there  is  no  room  to  add  another  board,  or 
there  are  weight  and  power  considerations.  Repladng  the  existiiu  memory  chips  with 
denser  memory  chips  does  not  always  soh«  the  problem  either.  Special  requirements 
are  placed  on  systems  when  memory  must  be  radiation  hardened.  Density  and  cost  of 
this  type  of  memory,  which  is  necessary  in  many  military  applications,  do  not  lend 
themselves  to  "just  ^ding  more". 

*  Single  Chip  Computers.  Use  of  Large  Scale  Integration  (LSI)  single  chip  computers 
often  restricts  memory  to  less  than  4KB  of  ROM  and  256  cytes  of  RAM.  These 
processors  increase  reiiabiliw  and  reduce  costs  in  areas  where  they  can  support  the 
processing  required.  Other  benefits  include  lower  power  consumption  ana  reduced 
weight  and  size. 

In  summa^,  fifty-six  percent  of  the  projects  interviewed  reported  that  memory  was  a 
constraint  in  their  system.  Althou^  harawve  engineers  can  provide  numerous  reasons  why 
additional  memory  cannot  be  ad&d  (e.g.  increased  weight,  mcreased  power  consumption. 


is  to  be  used  in  all  weapon  system  software. 

Pipblem  Resolution:  (Short  Term)  Hardware  designers  should  be  made  aware  of  the 
directive  to  use  Ada  in  weapon  systems,  and  ii^lude  sufficient  memory  in  their  designs  to 
accommodate  Ada. 

(Short  Term)  An  investigation  into  the  expansion  of  memory  for  embedded  computers  is 
needed.  Information  about  optimal  memory  technologies  has  to  be  provided  to  the 
hardware  designers. 

Another  solution  might  be  to  subset  use  of  language  features  and  optimize  for  that  subset. 
3.1.U  Dynamic  Priorities 

fssue/Problem  Definition:  There  isn't  any  provision  for  dynamic  priorities  of  tasks  in  the 
Ada  language. 
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Background:  A  task  is  said  to  have  a  "dynamic  priority"  if  its  priority  level  is  changeable  at 
execution  time.  Some  applications  have  the  need  to  dynamiodly  alter  the  priority  of  a 
currently  running  task. 

This  information  was  supplied  by  the  following  sources:  ARTEWG  &  SIGAda  Meetings, 
and  LabTek  Experience. 

Analysis  <fe  Support:  Ada  does  not  support  a  capability  for  dynamically  altering  the  priority 
of  a  currently  running  task.  The  value  for  the  PRAGMA  PRIORITY  is  static  and  therefore 
cannot  be  chanced  at  runtime.  Implementations  may  support  an  alternate  set  of  priorities 
^at  control  taslang  in  the  case  where  the  Ada  PRIORITY  is  identical  or  undefined.  That 
is,  if  two  t^ks  have  the  same  priority,  the  implementation  is  free  to  schedule  them  in  any 
order.  This  allows  an  implementation  defined  rabpriority,  which  may  be  dynamic,  to 
control  the  scheduling.  This  capability  is  not  supported  by  mai^  implementations,  and  a 
standard  does  not  exist  to  help  provide  commonality. 

In  summary,  dynamic  priorities  are  retted  by  some  real-time  applications,  and  they  are 
not  provided  for  by  the  Ada  language,  ^e  user  can  implement  a  limited  form  of  dynamic 
priorities  with  considerable  effort 

Problem  Resolution:  (Long  Term)  The  areas  of  the  langu^e  that  do  not  directly  support 
application  requirements  should  be  evaluated  to  determine  if  a  consistent  approach  to 
support  these  requirements  is  possible.  If  these  services  can  be  provided  in  an  acceptable 
manner  without  a  language  change,  then  this  is  the  desired  approach.  However,  in  some 
cases  it  may  be  desirable  to  make  small,  conmatible  changes  in  the  language  in  order  to 
accommodate  these  requirements  in  a  more  efficient  and  consistent  fashion. 

(Lone  Term)  Changes  to  the  standard  for  the  Ada  Language  (ANSI/MIL-STD-1815A)  that 
would  alleviate  problems  encountered  by  real-time  embedded  systems  should  be 
considered.  Although  maJdng  specific  changes  is  beyond  the  scope  of  study,  a  possible 
candidate  for  evaluation  is  "Dynamic  Priorities". 

3.1.1.6  Parallel  Processing 

Issue/Problem  Definition:  Current  RTFs  do  not  support  parallel  processing. 

Background:  Most  signal  processing  functions  require  parallel  data-path  computers. 

This  information  was  supplied  by  the  following  sources:  ARTEWG  <St  SIGAda  Meetings, 
and  LabTek  Ejq}erience. 

Analysis  <i  Support:  The  Reference  Manual  for  the  Ada  Programming  Language,  section 
4i(S),  states  that  operands  of  an  expression  "are  evaluated  in  some  order  that  is  not  defined 
by  the  langu^e".  This  tqipean  to  exclude  parallel  execution,  as  would  be  the  case  in  a 
MIMD  (multiple  instruction  multiple  data)  machine.  Confiision  is  provided  by  the  note  in 
the  Reference  Manual,  section  9(S),  that  talks  about  the  flexibility  to  use  multiple 
processors  when  the  same  effect  is  guaranteed.  However,  this  is  just  a  note  and  not 
technically  part  of  the  standard. 

Further  clarification  is  provided  in  the  "Rationale  for  the  Design  of  the  Ada  Programmini 
Language."  In  section  i.8,  "Assignment  Statements  -  The  Ada  Model  of  Time",  on  page  29 
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paragraph  7,  it  states:  "Note  finally  tlm  whenever  order  is  not  defined,  the  reference 
manual  uses  the  phrase  ’in  some  order  that  is  not  defined’,  rather  than  the  phrase  'in  any 
order*.  The  intent  of  the  chosen  wording  is  to  leave  the  order  undefined  but  nevertheless 
require  that  it  be  done  in  some  order,  and  thus  EXCLUDE  PARALLEL  EVALUATION", 
[emphasis  added]. 

The  Rationale  continues  with  the  reason  for  this  restriction.  This  issue  and  others  similar  to 
it,  notably  in  the  constraint  checking/lmdling  areas,  seem  to  be  overly  restrictive  with 
respea  to  parallel  architectures.  Specifically,  single  instruction  multiple  data  (SIMD), 
multiple  instruction  multiple  data  (MIMD),  and  massively  parallel  processon  (MPP),  will 
be  extremely  limited  if  relaxation  of  this  interpretatioa  is  not  forthcoming. 

Problem  Resolution:  (Long  Term)  The  areas  of  the  language  that  do  not  directly  support 
application  requirements  should  be  evaluated  to  determine  if  a  consistent  approach  to 
support  these  requirements  is  possible.  If  these  services  can  be  provided  in  an  acceptable 
manner  without  a  language  change,  then  this  is  the  desired  approach.  However,  in  some 
cases  it  may  be  desirule  to  make  small,  cot^tible  changes  m  the  language  in  order  to 
accommodate  these  requirements  in  a  more  emdent  and  consistent  fashion. 

(Long  Term)  Changes  to  the  standard  for  the  Ada  Language  (ANSI/MIL-STD-1815A)  that 
would  alleviate  problems  encountered  by  real-time  embedded  systems  should  be 
considered.  Although  making  specific  changes  is  beyond  the  scope  of  this  study,  a  possible 
candidate  for  evaluation  is  "Parallel  Procosmg”. 

3.1.1.7  Support  of  Low  Level  Operations 

Issue/Problem  Definition:  Ada  does  not  provide  a  mechanism  to  control  the  processor  state 
(including  interrupt  masks  required  for  critical  sections). 

Background:  Although  Ada  provides  a  mechanism  to  directly  manipulate  memory  mapped 
hardware,  no  <^abuity  exists  within  the  language  to  access  internal  processor  registers. 
Such  a  mechanism  would  be  difficult  to  standardize  across  many  architectures. 

This  information  was  supplied  by  the  following  sources:  Project  Interviews,  and  LabTek 
Experience. 

Analysis  <£  Suppon:  Provision  should  be  made  in  implementations  so  that  users  can  control 
the  processor  state  and  not  interfere  with  the  runtime  system.  For  exaimle,  some 
implementations  require  that  the  application  run  in  a  non>privileged  state  (USER  MODE). 
This  is  not  aiwaM  acceptable,  and  simply  executing^an  assembly  language  routine  to  chamm 
to  SYSTEM  MODE  will  not  solve  the  problem.  Changing  the  processor  state  from  USER 
to  SYSnr^4,  needs  to  be  done  in  conjunction  with  the  runtune.  Since  stacks  used  for 
different  states  are  often  separate,  sinq}ly  changing  state  will  result  in  an  error  condition. 
Also,  subsequent  ealh  to  ^  runtime  (possibly  due  to  exceptions)  are  likely  to  cause 
unpredictable  results. 

In  summary,  in  real-time  programming  there  is  frequently  a  need  to  enable  and  di^le 
interrupts  which  is  performed  by  setting  or  clearing  interrupt  niask&  It  is  easy  for  a 
programmer  to  write  an  assembly  language  routine  to  manipulate  an  interrupt  mask  and 
c^  this  routine  from  an  Ada  program.  The  problem  ocean  because  the  assembly  language 
routine  is  not  working  in  conjunction  with  the  runtime  environment  provided. 
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Unpredictable  results  could  occur.  The  way  for  the  user  to  manipulate  interrupt  masks 
(and  processor  state)  without  interfering  with  the  runtime  is  to  have  the  compiler  vendors 
supply  a  routine  to  do  this  that  is  compatible  with  their  runtime  environment. 

Problem  Resolution:  (Long  Term)  Provision  should  be  made  in  implementations  so  that 
users  can  control  the  processor  state,  and  not  interfere  with  the  runtime  system. 

(Long  Term)  The  areas  of  the  language  that  do  not  directly  support  application 
requirements  should  be  evaluated  to  determine  if  a  consistent  approach  to  support  these 
requirements  is  possible.  If  these  services  can  be  provided  in  an  acceptable  manner  without 
a  language  change,  then  this  is  the  desired  approach.  However,  in  some  cases  it  may  be 
desirable  to  make  small,  compatible  changes  in  the  language  in  order  to  accommodate 
these  requirements  in  a  more  emcient  and  consistent  fashion. 

(Long  Term)  Changes  to  the  standard  for  the  Ada  Language  (ANSI/MIL-STD'1815A)  that 
would  alleviate  problems  encountered  by  real*time  embedded  systems  should  be 
considered.  Although  making  specific  changes  is  beyond  the  scope  of  t^  smdy,  a  possible 
candidate  for  evaluation  is  "Sup^rt  of  Low  Level  Operations". 

3. 1.1.8  Task  Restart 

Issue/Problem  Definition:  Applications  which  require  that  a  separate  thread  of  control 
(task)  be  restarted  at  the  beguining  after  being  interrupted  part  way  through  have  difheuity 
mapping  this  requirement  to  Ada. 

Background:  An  example  where  a  task  restan  would  be  needed  is  in  the  following  situation: 
Suppose  that  an  aircr^  was  on  a  mission  to  deliver  a  weapon  to  a  specified  target.  The 
pilot  flies  within  the  vicinity  of  the  target.  The  flight  control  software  activates  an  Ada  task 
which  calculates  the  current  aircraft  position  as  well  as  the  target  position.  Before  this  task 
can  complete,  a  task  of  higher  priority  becomes  active,  a  task  to  defend  the  aircraft  against 
incoming  threats.  The  puot  j^rfoims  the  necessary  defensive  maneuvers  and  once  the 
threat  is  no  longer  a  thre^  the  pilot  resumes  with  the  mission  to  deliver  the  weapon  to  the 
target.  However,  the  aircraft  is  no  longer  at  the  same  position  that  the  previously 
suspended  Ada  task  recorded.  If  the  suspended  Ada  task  became  active  now,  the  positional 
information  would  be  wrong  and  would  lead  to  disastrous  results.  What  is  needed  here  is 
the  ability  to  restan  this  tas£ 

This  information  was  supplied  by  the  following  somces:  ARTEWG  &  SIGAda  Meetings. 

Analysis  <k  S^porr.  The  obvious  question  is:  is  this  really  a  requirement,  or  simply  the 
implementation  of  a  requirement?  After  careful  scrutiny,  it  appears  that  certain 
applications  do  have  a  neM  to  be  able  to  have  multiple  tasl^  where  one  task  might  be 
preempted  by  a  higher  priority  task,  and  the  result  of  the  preemption  is  to  make  the 
continuation  of  the  preeix^ted  task  meaningig^^.  The  standard  Ada  solution  to  this 
problem  is  to  ABORT  the  i^eempted  task,  and  then  re-aedvate  a  new  task.  This  creates  a 
tew  undesirable  side  effects,  not  toe  least  of  which  is  likely  to  be  unacceptable  performance 
degradation. 

In  summary,  there  are  real-dme  applications  which  have  a  need  for  a  task  restart  capability. 
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Note:  Preliminaiy  Ada  (May  1979)  provided  for  an  exception  "FAILURE"  to  be  raised 
within  one  task  from  another  task.  This  would  support  the  desired  effect  of  Task  Restan", 
however  the  feature  was  removed  from  the  language  prior  to  the  1980  version. 

Problem  Resolution:  (Long  Term)  The  areas  of  the  language  that  do  not  directly  support 
application  requirements  should  be  evaluated  to  determine  if  a  consistent  approach  to 
support  these  requirements  is  possible,  ff  these  services  can  be  provided  in  an  acceptable 
manner  without  a  language  change,  then  this  is  the  desired  approach.  However,  in  some 
cases  it  may  be  desirable  to  make  small,  coiraatible  changes  m  the  language  in  order  to 
accommodate  these  requirements  in  a  more  emdent  and  consistent  fashion. 

(Long  Term)  Changes  to  the  standard  for  the  Ada  Language  (ANSI/MIL-STD-1815A)  that 
would  alleviate  problems  encountered  by  reai>time  embedded  systems  should  be 
considered.  Although  making  specific  changes  is  beyond  the  scope  of  this  study,  a  possible 
candidate  for  evaluation  is  Task  Restart”. 

3. 1.1.9  Cyclic  Scheduling 

Issue/Problem  Definition:  There  is  no  explicit  provision  for  cyclic  executives  in  the  Ada 
language. 

Backpound:  A  ^ciic  executive  runs  on  a  scheduled  time  basis  and  is  either  difficult  or 
impossible  to  achieve  with  accuracy  on  many  implementations. 

The 

loop 


end  loop; 

structure  is  not  sufficient  since  it  is  not  periodic  If  different  control  paths  are  taken  within 
the  loop,  or  if  other  tasks  (possibly  interrupt  level)  preempt  execution,  then  this  loop  will 
not  execute  in  constant  time. 

This  informadon  was  supplied  by  the  following  sources:  ARTEWG  &.  SIGAda  Meedngs, 
and  LabTek  Experience. 

Analysis  <£  Supporr.  The  Ada  language  can  suppon  some  degTM  of  periodic  processing  by 
using  the  DbLAY  statemenL  Although  some  implementadons  provide  a  reasonable 
mechanism  for  thia,  the  DELAY  Statement  is  not  uways  adequate  for  this  applicadon. 
(Note:  many  people  are  concerned  with  the  wording  in  the  Reference  Manual  for  the  Ada 
Programming  I  angiiage  regarding  the  accuracy  of  the  del^  in  a  DELAY  Statement:  "...for 
at  least  the  duration  specmra  by  the  resulting  value”.  This  is  not  the  problem,  although  it 
can  contribute  to  it)  Assuming  that  an  implementation  has  infinite  accuracy  for  type 
DURATION  and  DELAYS  exactly  that  amount,  there  is  still  a  problem  specifying  the 
duradon  for  a  cydic  task.  The  problem  is  that  the  duranon  value  is  a  delay  from  the  cmem 
time,  not  a  fixed  intervaL  Therefore,  the  dock  must  be  read  and  the  cycle  computed  in  the 
simpie^expression  allowed  for  the  delay  statement  However,  there  is  no  way  to  insure  that 
an  interrupt  (and  possibly  a  higher  priority  task)  is  not  executed  between  the  time  the  clock 
is  read  in  the  simple  expression  and  when  the  delay  duradon  is  actually  interpreted  by  the 
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runtime.  This  allows  the  execution  of  the  ^cle  to  begin  with  possibly  twice  as  much  jitter  as 
what  would  normally  be  expeaed  due  to  hi^er  priority  processing. 

In  summary,  cyclic  executives  are  an  ir^ortant  part  of  real-time  embedded  software.  How 
they  are  implemented  in  Ada  is  something  that  requires  careful  consideration. 

Non-Solutions:  An  implementation  could  provide  a  pragma  that  would  insure  that  the 
expression  in  the  following  DELAY  statement  is  implemented  as  non-interruptible,  thus 
resolving  this  issue,  but  at  the  price  of  being  rather  messy  (not  recommended). 

Ano^er  non-solution  is  the  use  of  interrupt  tasks,  and  using  a  hardware  interval  timer  to 
provide  the  periodic  scheduling.  This  work  in  some  applications,  but  for  those 
applications  that  have  several  ditierent  periods,  this  quickly  becomes  unmanageable. 

Problem  Resolution:  (Long  Term)  The  areas  of  the  langu^e  that  do  not  directly  suppon 
application  requirements  should  be  evaluated  to  determine  if  a  consistent  approach  to 
support  these  requirements  is  possible.  If  these  services  can  be  provided  in  an  acceptable 
manner  without  a  language  change,  then  this  is  the  desired  approach.  However,  in  some 
cases  it  may  be  desirable  to  make  small,  co^atible  changes  m  the  language  in  order  to 
accommodate  these  requirements  in  a  more  emcient  and  consistent  fashion. 

(Long  Term)  Changes  to  the  standard  for  the  Ada  Language  (ANSI/MIL-STD-1815A)  that 
would  alleviate  problems  encountered  by  real-time  embedded  systems  should  be 
considered.  Although  making  specific  changes  is  beyond  the  scope  of  this  study,  a  possible 
candidate  for  evaluation  is  "Cydic  Scheduling". 

3.1.1.10  Floating  Point  Coprocessor  Support 

Issue/Problem  Definition:  There  is  a  lack  of  a  standard  for  floating  point  coprocessor 
support.  Some  compilers  require  a  floating  point  chip  to  perform  floating  point 
calculations,  other  compilers  can’t  utilize  the  chip  ii  present 

Backhand:  A  floating  point  coprocessor  is  a  high-performance  numerics  processing 
element  that  extends  the  main  processor  architecture  by  adding  significant  numeric 
capabilities  and  direct  support  for  floating-point,  extended  integer,  and  BC^data  types. 

This  information  was  supplied  by  the  following  sources:  Project  Interviews,  and  LabTek 
Experience. 

Analysis  <k  Support:  Applications  should  have  the  option  to  run  with  or  without  a 
coprocessor.  Ail  compilers  should  provide  floating  point  capabilities  independent  of 
whether  the  floating  pomt  processor  is  configured  into  the  system  or  noL 

The  presence  of  a  floating  point  chip  would  increase  performance  in  a  real-time  embedded 
application  that  requiied  floating  point  operations  to  oe  performed.  On  the  other  hand,  an 
application  may  not  be  able  to  repackage  to  include  a  floating  point  chip  on  the  board  and 
this  application  could  utilize  a  software  floating  point  emulation. 

The  use  of  tasldng  introduces  additional  overhead  when  the  floating  point  dup  is  present 
The  floating  point  coprocessors  contain  internal  registers  which  must  be  saved  and  restored 
during  task  switches.  Ideally,  intelligent  context  switch  software  (or  hardware)  would  only 
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save  and  restore  these  registers  when  a  context  switch  occurs  to  a  task  that  uses  floating 
point,  instead  of  when  any  context  switch  occurs. 

Also,  the  support  for  the  intrinsic  functions  such  as  sine  and  cosine  are  important  These 
functioas  are  not  part  of  the  Ada  language  and  need  not  be  supplied  by  an  Ada  compiler 
vendor  to  validate.  A  numerics  workmg  group  exists  within  SIGAda  to  attempt  to 
standardize  the  interface  to  common  numeric  fimctioDS.  For  the  greatest  amount  of 
efficiency,  it  is  usually  best  that  the  vendor  supply  these  Unctions  as  a  special  package.  This 
allows  the  implementation  to  take  advantage  of  the  hardware  that  is  available.  When  a 
math  coprocessor  is  supported,  it  should  be  used  to  implement  these  functions,  since  their 
calculation  is  often  greater  than  fifty  times  faster  using  the  hardware  coprocessor.  With 
proper  compiler  optimization  and  use  of  the  INLINE  pragma,  it  can  be  possible  to  achieve 
nearly  optimal  use  of  floating  point  acceleraton  even  with  user  written  packages. 

In  summary,  the  decision  to  use  the  floating  point  chip  should  be  up  to  the  application 
proo’ammer  and  the  Ada  compiler  should  penorm  properly  with  or  witnout  the  presence  of 
the  fioadng  point  chip. 

Problem  Resolution:  (Short  Term)  The  evaluation  of  compilers  should  include  a  section 
regarding  the  support  level  for  coprocessors. 

3.1.1.11  Distributed  Processing 

Issue/Problem  Definition:  There  are  no  commercially  available  Ada  implementations 
whose  runtime  environments  support  distributed  computer  configurations  that  operate  over 
communication  links. 

Backgmimd:  A  distributed  system  is  a  configuration  of  processors,  memories,  and  links  in 
which  each  processor  has  a  designated  local  memory  that  it  can  access  in  significantly  less 
time  than  it  can  access  either  mared  memory  or  the  loc^  memory  of  other  processors. 
Typically,  such  systems  have  a  high  bandwidth  communication  link  between  processors  but 
little  or  no  shared  memory.  The  key  to  efficient  use  of  these  systems  is  to  s^cture  the 
system  and  distribute  the  work  load  so  as  to  limit  the  interprocessor  communication.  [14] 

This  information  was  supplied  by  the  foUowii^  sources:  Project  Interviews,  ARTEWG  & 
SIGAda  Meetings,  Current  Softvme  Engineering  Literature,  and  LabTek  Experience. 

Analysis  Support:  Progress  has  been  made  in  the  area  of  shared-memory  multiprocessor 
implementations  of  Ada,  however  the  technology  is  closely  coupled  to  the  hardware 
comguration  and  cannot  be  easily  migrated  to  other  targets.  Currently,  distributed 
processor  software  is  most  often  being  develop^  as  indwiduai  Ada  programs  with  custom 
communication  services  rmher  than  as  monolithic  Ada  programs. 

In  summary,  there  is  no  common  approa^  to  developing  runtime  environments, 
methodologies,  and  tools  that  support  the  distribution  of  Ada  program  entities  aaoss 
multiprocessor  configurations  or  distributed  networks.  [4] 

Problem  Resolution:  (Long  Term)  Distributed  processing,  in  the  sense  that  Ada  tasia  from 
a  sin^e  program  are  distnbuted  across  several  processors  connected  by  a  communication 
link,  is  an  area  that  still  requires  rrjearch  and  development.  Solving  the  problems  of 
communication  errors,  possible  failure  of  a  processor,  and  implementing  efficient 
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"SELECT"  statements  for  the  Ada  rendezvous  will  require  more  time  and  effort  before  the 
results  are  available  to  the  general  public 

3.1.1.12  Multi-level  Security  Support 

Issue/Problem  Definition:  Ada  nmtime  environments  do  not  currently  support  multi-level 
security. 

Background:  Security  is  the  protection  of  computer  hardware  and  software  &om  accidental 
or  malicious  access,  use,  mooificadon,  destruction,  denial  of  service,  or  disclosure.  [11] 

This  information  was  simplied  by  the  following  sources:  Project  Interviews,  ARTEWG  & 
SIGAda  Meetings,  and  Current  Software  Engineering  Literamre. 

Anafysis  Support:  The  vast  amount  of  software  being  developed  is  for  large  distributed 
battlefield  computer  systems.  These  ^tems  tend  to  involve  many  different  aspects  of 
battle  management  ranging  from  tracking  and  launching  to  maintaining  personnel  records. 
Likewise,  the  operators  tend  to  have  dmerent  security  requirements,  ^e  need  for  the 
software  to  be  ouilt  on  top  of  a  secure  operating  system  stems  fit>m  these  conditions.  An 
officer  who  needs  only  to  assess  the  current  ammunition  reserves  should  not  be  able  to 
launch  weapons. 

In  summary,  without  providing  a  secure  base  upon  which  the  Ada  applicadon  runs,  security 
in  an  integrated  battlefield  system  cannot  be  insured.  It  is  possible  to  develop  an  Ada 
application  layered  on  top  of  an  existing  secure  operating  ^tem,  but  available  secure 
operating  systems  are  currently  not  very  suitable  for  most  real-time  embedded  applications. 

However  there  are  many  small  projects  that  are  unlikely  to  require  multi-level  security  since 
they  are  stand-alone  processors  with  a  limited  number  of  fiinctions,  all  at  the  same  security 
level. 

Problem  Resolution:  (Long  Term)  Like  Distnbuted  Processing  above,  the  area  of  security 
will  require  time  and  effort  before  small,  efficient,  secure  runtimes  are  available  for  use  on 
real-time  embedded  ^tems.  If  this  area  is  a  priority  for  the  military,  then  it  will  probably 
require  special  funding.  Since  the  perception  of  a  weak  market  for  secure  embedded 
systems  exists,  commerdai  compiler  vendors  will  need  encouragement  to  devote  resources 
to  this  effort 

3.1.1.13  Reliability 

Issue/Problem  Definition:  With  respect  to  software  reliability^,  Ada  systems  are  too  new  to 
provide  ^  significant  data  as  to  whether  programs  written  in  Ada  are  more  reliable  than 
those  written  in  other  languages.  Rehabili^  in  Ada  systems  is  not  seen  as  a  problem  at  this 
time,  and  this  section  was  only  included  for  con^leteness. 

Background:  Reliability  is  the  abili^  of  an  item  to  perform  a  required  fimction  under  stated 
conditions  for  a  stated  period  of  time.  Software  reliability  is  the  probability  that  software 
will  not  cause  the  failure  of  a  system  for  a  specified  time  under  specified  conations.  It’s  the 
ability  of  a  program  to  perform  a  required  function  under  stated  conditions  for  a  stated 
period  of  time,  fll] 
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This  informatioa  was  supplied  ^  the  following  sources:  Project  Interviews,  ARTEWG  &. 
SIGAda  Meetings,  and  LaoTek  Experience. 

Anafysis  dc  Support:  As  experience  with  Ada  technology  increases,  more  information  will 
become  available  as  to  the  reliability  of  the  systems  developed  in  Ada.  It  is  felt  that  the 
strong  typing  mechanism  of  Ada  is  extremely  valuable  with  respect  to  reliability.  This 
mechani^  msures  that  all  variables  are  identmed  and  typed  and  assignments  are  checked 
to  be  valid  at  execution  time. 

Due  to  the  imznarturity  and  frequent  updates  for  Ada  compilers,  a  short<term  reliability 
problem  may  be  found  with  some  implementations  because  of  errors  with  the  compilation 
and/or  runtime  systems. 

Problem  Resolution:  Since  reliability  does  not  present  a  problem,  there  is  no  problem 
resolution  required  at  present 

Issue/Problem  Definition:  With  respect  to  supporting  hardware  reliability,  Ada  does  not 
address  the  reliability  issue  with  ai^  specific  language  constructs. 

Back^ourtd:  CPU  fault  tolerance  is  the  built*in  capability  of  a  system  to  provide  continued 
correa  execution  in  the  presence  of  a  limited  numMr  of  hardware  or  softie  faults.  [11] 

This  information  was  supplied  ^  the  following  sources:  Project  Interviews,  ARTEWG  & 
SIGAda  Meetings,  and  l^Tek  experience. 

Anafysis  <k  Support:  Ultra  high  reliable  systems  require  that  the  software  continue  to 
operate  in  the  presence  of  CPU  faults.  Although  this  may  seem  impossible,  careful  analysis 
indicates  that  many  faults  (for  exa^le  nudear  EMP)  are  momentary  and  do  not  result  in 
permanent  interruption  in  processing  capability.  However,  it  is  essential  that  the  program 
oe  able  to  recover  from  such  fiuilts  and  continue  execution  from  ±e  last  check  point.  In 
ballistic  missile  systems  check  points  may  be  as  dose  as  a  few  instructions  in  order  to 
minimize  the  disruption.  The  program  must  constantly  be  storing  multiple  copies  of  check 
point  addresses  and  data  used  m  computations.  Ada  does  not  directly  support  the  ability  to 
recover  &om  such  CPU  faults. 

In  summary,  Ada  does  not  support  hardware  reliability  with  specific  language  constructs. 
Exception  handlers  are  proviora  to  detect  software  faults,  but  in  rare  cases  may  also  be 
used  to  detect  and  recover  firom  hardware  faults. 

Problem  Resolution:  (Long  Term)  Reliability  in  this  context  is  specific  to  recovery  from 
CPU  faults.  Although  it  is  possible  for  an  A^  program  to  check^int  its  data,  due  to  the 
complexity  of  program  elabOTation,  it  would  be  difficult  with  an  off*the*shelf  runtime  to 
roll'Oack  and  recover  from  a  CPU  reset.  Unlike  assembly  language  routina  where  data  is 
largely  statically  allocated,  Ada’s  dynamic  nature  of  data  reconstruction  onich  more 
difficult-  Research  and  development  needs  to  be  done  to  resolve  the  impact  of  using  Ada  in 
the  most  critical  applications  areas  where  extended  interruption  of  service  is  unacceptable. 

3.12  Code  Quality 

Issue/Problem  Definition:  The  quality  of  the  generated  code,  in  terms  of  being  optimal,  was 
a  major  problem  for  many  real«tune  embedded  systems. 
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Background:  The  quality  of  the  generated  code  has  a  tremendous  impact  on  the  ability  to 
use  a  compiler  for  real-time  software  production.  Ideally,  the  code  generated  by  the 
compiler  would  be  nearly  as  efficient  as  what  an  e:q)erienced  assembly  lai^age 
pro^ammer  could  produce.  This  has  always  been  an  elusive  goal,  however  it  is  not  unheard 
of  to  have  some  programs  developed  in  a  high  level  language  perform  better  than  their 
assembly  language  counterparts.  This  is  generally  due  to  an  Improved  algorithm  that  was 
practical  to  implement  because  of  the  high  level  language. 

This  information  was  supplied  by  the  following  sources:  Project  Interviews,  ARTEWG  & 
SIGAda  Meetings,  Current  Sofm^e  Engineering  Literature,  and  LabTek  Experience. 

Anafysis  &.  Support.  In  Ada,  optimization  is  very  important  in  order  to  eliminate 
unnecessary  runtime  checking.  Although  the  runtime  checics  can  be  suppressed,  it  is  often 
desirable  to  leave  them  on  to  detect  latent  software  faults,  or  even  some  Imthvare  faults. 

Subprogram  invocation  is  another  very  important  area  for  optimizatioa  Due  to  the  strict 
rules  of  passing  parameters,  elaborating  and  initializing  lo^  objects,  and  entering  new 
exception  scopes  for  each  subprogram  call,  it  is  essential  that  this  mechanism  be  kept  as 
effiaeht  as  pc^ible. 

There  is  no  substitution  for  having  optimized  code.  The  difference  between  optimization 
and  no  optimization  can  be  as  much  as  15  to  1  or  greater  in  performance,  although  ^ical 
numbers  are  much  smaller.  The  excuse  that  computer  hardware  is  much  faster  than  it  used 
to  be,  and  therefore  code  efficiency  is  no  longer  as  important,  is  only  partially  true.  The 
efficiency  that  can  be  sacrificed  so  that  a  high  order  language  can  be  used  varies 
tremendously  from  application  to  application.  In  general,  knowing  the  code  qu^ty  of  the 
proposed  compilation  system  should  be  a  major  concern,  so  that  the  appropriate  speed 
processor  can  be  selected  for  the  application. 

In  summary,  eighty-one  percent  of  the  projects  interviewed  reported  that  the  quality  of  the 
generated  code  was  a  major  problem  for  reai-time  embedded  a^lications. 

Non-Solution:  When  confronted  with  a  large  overhead  in  subprogram  invocation  the 
alternative  is  to  force  programmers  away  from  the  modulariw  of  suoprograms  and  back  into 
straight-line  coding  pracnces.  In  some  cases  the  pragma  ImJNE  can  be  used  to  generate 
the  subprogram  statements  in  line  at  the  point  of  call,  and  to  avoid  much  of  the  overhead 
associated  with  the  calling  sequence.  However,  this  can  become  impractical  when  calls  are 
made  to  the  subprogram  from  many  points  in  the  program  due  to  the  large  expansion  in 
code  size. 

Non-Solution:  The  measure  of  last  resort  is  to  fall  back  to  assembly  language  in  the  most 
time  critical  aspects  of  the  program.  This  worlo  very  well  for  applications  that  are  large,  but 
have  a  small  real-time  component  All  too  often  however,  programs  tend  to  have  time 
critical  portions  spread  throughout  In  these  cases,  the  high  level  code  portion  looks  like 
initialization  code  that  calls  the  main  assembly  language  program  (not  recommended). 

Problem  Resolution:  (Long  Term)  The  area  of  code  quality  can  be  resolved  by  ^plying 
commercial  incentives  on  vendors  improving  their  prooucts.  This  can  be  accomplished  by 
implementation  of  the  recommendation  specified  under  section  3.1.13. 
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3.1J  Documentation 

Issue/Problem  Definition:  Areas  lacking  in  compiler  vendor  documentation  are  details 
concerning:  1)  critical  timing  parameters,  and  2)  the  runtime  environmenL 

Background:  In  this  section,  "documentation''  refers  to  the  compiler  documentation. 

This  information  was  suppUed  by  the  following  sources:  Project  Interviews,  and  LabTek 
Experience. 

Analysis  <fe  Support:  Sixty-three  percent  of  the  projects  interviewed  reported  that 
inadetfuades  were  encountered  witn  the  conq)iler  documentation.  This  was  particularly 
evident  in  the  area  of  criti<^  riming  parameters  (Le.,  task  context  swtch  time,  synchronous 
rendezvous  time,  complex  rendezvous  time,  and  mteriupt  latency  time).  Values  for  times, 
sudi  as  interrupt  latency  due  to  disabled  interrupts  within  the  runtime  are  usually  not 
provided  in  the  standard  documentation  (and  sometimes  impossible  to  obtain).  These 
values  are  needed  in  order  to  compute  what  variance  can  be  expected  with  the  DELAY 
statement  and  other  riming  issues.  It  is  extremely  difficult  to  use  benchmarks  to  measure 
this  type  of  riming-  Benchmarks  tend  to  show  q^ical  or  average  execution  times.  What  is 
often  moire  important  is  the  worst  case  time. 

This  issue  should  not  to  be  confused  with  the  information  supplied  in  Appendix  F  of  the 
compiler  documentation  entitled  "Implementadon-Dependent  Characteristics",  as  specified 
by  ANSI-MIL-STD-1815A-1983.  Appendix  F  specifies;  1)  The  form,  allowed  places,  and 
effect  of  every  implementation  dependent  pragma.  2)  Tne  name  and  the  type  of  eve^ 
implementation-dependent  attribute.  3)  The  specification  of  the  pack^e  SYSTEM.  4) 
The  list  of  ail  resiricrions  on  representation  clauses.  5)  The  conventions  used  for  my 
implementation-generated  name  denoting  implementation-dependent  component.  6)  The 
interpretation  of  expressions  that  appear  in  ^dress  clauses,  including  those  for  interrupts. 
7)  Any  restriction  on  uncheckeo  conversions.  8)  Any  implementation-dependent 
characteristics  of  the  input-output  padtages.  [2] 

The  best  method  for  determining  the  critical  tinting  parameters  is  to  analyze  the  code 
within  the  runtime.  The  disadvantage  is  that  often  this  mformation  is  needed  m  helpmg  to 
select  the  compiler,  and  often  it  is  not  provided  until  the  selection  has  been  made. 

An  example  of  an  inadequa^  in  the  runtinw  environment  section  is  that  it  is  difficult  to 
measure  dynamic  memory  »s^gff  on  some  implementanons.  TIu  is  usually  because  the 
documentation  does  not  provide  adequate  detaw  on  how  the  runtime  uses  dynamic  storage. 

In  summary,  the  currem  compiler  documentation  is  lac^  in  the  ineas  of  critical  timing 
parameters  and  runtime  environment  algorithms.  This  infonDanon  is  necessary  to  be  able 
to  evaluate  the  conqtiler  before  selection  and  shmild  be  provided. 

Problem  Resolution:  (Short  Term)  By  including  the  qu^ty  and  completeness  of  the 
compiler  rinrtiTTwtmarinii  in  the  evaluation  of  coix^nlers,  this  will  allow  users  to  select  the 
implementations  that  have  the  level  of  documentation  that  is  desired. 

3.1.4  Validation 
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Issue/Problem  Definition:  In  general,  the  compiler  implementor’s  thrust  has  been  towards 
validation  of  their  compilers  at  the  expense  of  p|Oor  optimization  of  its  generated  code, 
configurability  of  its  runtime  environment,  or  implementation  of  machine  dependent 
features. 

Background:  Validation  is  the  process  of  checking  the  conformity  of  an  Ada  rampiler  to  the 
Ada  programming  language  and  of  issuing  certificates  indicating  compliance  of  those 
compilers  that  have  been  successfully  tested  [1]  It  should  be  emphasized  that  the  intent  is 
only  to  measure  conformance  with  the  standard.  Any  validated  compiler  may  still  have 
bup  and  poor  performance,  since  performance  is  not  being  measured  by  the  validation 
tests.  [6] 

To  obtain  a  validation  certificate  a  compiler  implementor  must  exercise  an  Ada  Compiler 
Validation  Capability  (ACVC)  test  suite.  The  current  level  is  Version  1.9  and  it  contains  a 
series  of  over  2500  tests  desired  to  check  a  compUer’s  confommce  to  the  DoD’s  Ada 
language  standard,  ANSI/M1L-STD-1815A-1983.  To  date,  compiler  implementors  have 
been  very  concerned  with  obtaining  the  status  of  ’Validated”  for  their  compilers.  Having  a 
validated  Ada  compiler  is  no  longer  just  a  marketing  ploy,  it  is  required  by  the  DoD  that 
contraaors  developing  Ada  softv^e  must  use  a  vahoated  Ada  compiler  (DoD  Directive 
34052). 

This  information  was  supplied  by  the  following  sources:  Projea  Interviews,  and  Current 
Software  Engineering  Literature. 

Anafysis  &  Support:  With  the  initial  validation  phase  completed  for  most  compilers,  the 
compiler  implementors  are  shifting  their  emphasis  to  concentrate  on  improving  the 
effiaency  of  the  generated  code  (code  optimization)  and  providing  more  user 
configurability  of  the  runtime  environment 

Validation  issues  have  confused  many  application  builders.  Questions  have  arisen  as  to 
whether  or  not  similar,  but  not  identical,  hardware  that  was  used  for  validation  can  be 
considered  validated.  Other  issues  have  appeared  involving  what  constinites  "mamtenance" 
of  a  compiler,  and  how  much  of  it  can  unde^o  change  and  still  retain  vali^tion  status. 
Also,  since  Ada  validation  status  is  only  retained  for  one  year  after  validation,  concerns 
have  been  expressed  for  programs  that  do  not  want  to  change  the  version  of  ^eir  compiler 
after  they  begin  testing.  New  policies  have  been  developed  to  support  baselining  a  compiler 
with  respect  to  a  project,  and  deriving  validation  status  for  similarly  configured  machmes. 
Although  there  are  still  unresolved  issues,  the  associated  problems  are  minor  and  are 
unlikely  to  adversely  impact  any  development  programs. 

In  summary,  the  real-time  issues  of  performance,  support  for  low-level  operations  ^d 
decreasing  runtime  environment  sizes  have  taken  a  back  seat  to  obtaining  a  compiler 
validation  certificate. 

Problem  Resolution:  (Short  Term)  The  ACVC  must  be  expanded  to  include  all  of  the 
Chapter  13  feamres.  Information  on  the  new  validation  pohcy  should  be  provided  to  all 
PMs  and  government  contractors  using  Ada. 

3.1.5  Proposed  Ada  Language  Extensions 
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In  interyie^mg  various  engineers  the  following  language  features  were  desired  but  not 
present  tn  the  current  Reference  Manual  for  the  Ada  Programming  Language*  1.)  Support 
for  fast  interrupts,  2.)  Gr^er  control  of  the  Task  Control  Block  (TCB),  and  3.) 
Asynchronous  Task  Communications.  These  features  are  explained  further  mIow. 

3.1J.1  Fast  Interrupts 

Issue/Problem  Definition:  Fast  interrupts  are  not  e:q)licitly  supported  by  Ada. 

Background:  Support  for  fast  interrupts  would  allow  the  application  engineer  to  specify  that 
an  intenupt  task  will  not  require  the  runtime  to  perform  a  full  context  switch  on  interrupt 
entry  (Le.  the  interrupt  task  executes  in  the  context  of  the  currently  active  task).  This  is 
necessary  in^rder  to  provide  immediate  response  to  hardware  events. 

This  information  was  supplied  the  following  sources:  Project  Interviews,  ARTEWG  & 
SIGAda  Meetings,  and  LabTek  experience. 

Anafysis  <k  Support:  Some  compiler  implementations  provide  this  capability  with  an 
implementation  dependent  PRAGMA. 

Problem  Resolution:  (Short  Term)  The  suggestion  is  to  mg»ri»  this  a  standard  PRAGMA. 

(Long  Term)  Changes  to  the  standard  for  the  Ada  Language  (ANSI/MIL-STD-1815A)  that 
would  alleviate  problems  encountered  by  real>time  embedded  systems  should  be 
considered.  Although  making  specific  changes  is  b^ond  the  scope  of  this  study,  a  possible 
candidate  for  evaluation  is  "Fast  Interrupts". 

3.1.52  Greater  Control  of  the  Task  Control  Block  (TCB) 

Issue/Problem  Definition:  Application  engineers  are  not  able  to  manipulate  the  TCB  in 
most  implementations. 

Background:  The  task  control  block  contains  such  information  as:  task  priority,  amount  of 
time  allocated  to  a  time  slice,  status  of  the  task,  etc. 

This  information  was  supplied  by  the  following  sources:  Project  Interviews,  and  LabTek 
Experience. 

Arutfysis  <k  Support  The  application  exigineer  would  benefit  if  able  to  manipulate  the  task 
control  block.  This  is  not  a  severe  problem  for  most  applications.  The  applications  which 
require  this  capability  are  the  ones  that  are  trying  to  write  operating  systems  in  Ada.  An 
operating  system  makes  extensive  use  of  and  the  alnlity  to  spet^  the  time*slice 

period,  among  other  task  characteristics,  is  desirable 

Problem  Resolution:  (Long  Term)  Chanses  to  the  standard  for  the  Ada  Langu^e 
( ANSI/MBL-S  n>l815A)  that  would  alfaviate  problems  encountered  by  real-time 
embedded  systems  should  be  considered.  Although  pairing  specific  changes  is  bevond  the 
scope  of  this  study,  a  possible  candidate  for  evaluation  is  "Control  of  Task  ^ntrol  Block”. 
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3.U  J  Asynchronous  Task  Communications 

Issue/Problem  Definition:  The  Ada  rendezvous  model  uses  a  synchronous  mechanism  to 
communicate  between  tasks.  Many  applications  require  that  a  signalling  task  not  be 
delayed  until  the  signalled  task  is  ready  to  accept  the  signal 

Background:  The  mechanism  used  to  communicate  between  tasks  in  the  Ada  rendezvous 
model  is  that  both  tasks  must  be  synchronized  together  before  any  data  or  control 
information  can  be  transferred.  This  u  dissimilar  to  me  conventional  mailbox  techniques 
utilizing  P  and  V  semaphores  to  provide  inter-task  communications. 

This  information  was  supplied  ^  the  following  sources;  Project  Interviews,  ARTEWG  & 
SIGAda  Meetings,  and  L^Tek  luqmrience. 

Analysis  dc.  Support:  The  a^ment  for  the  Ada  model  is  that  it  provides  a  unified  approach 
for  bom  data  communication  and  generating  events  (signalling).  However,  many 
applications  require  mat  a  signalling  task  not  be  delayed  by  waiting  while  me  signalled  task 
is  not,ready  to  rendezvous. 

Problem  Resolution:  (Work-Around)  The  Ada  solution  to  this  issue  is  to  place  an 
irtsrmediate  task  between  me  signalling  task  and  me  waitm^  task.  This  intermeoiate  task 
would  always  be  ready  for  a  rendezvous  and  would  effectively  buffer  me  transaction  to 
effectively  provide  asynchronous  communications.  The  impact  is  to  create  an  additional 
(logical)  context  switch.  In  the  absence  of  an  optimization  which  would  eliminate  me  need 
of  this  additional  context  switch,  me  approach  is  not  suitable  for  time  critical  applications. 
The  combination  of  supporting  fast  interrupt  tasks  and  asynchronous  signals  makes  this 
optimization  difficult  for  general  use. 

(Long  Term)  Changes  to  me  standard  for  me  Ada  Language  (ANSI/MEL-STD-ISISA)  mat 
would  alleviate  problems  encountered  by  real-time  embedded  systems  should  be 
considered.  Aimough  making  specific  changes  is  beyond  me  scope  of  this  study,  a  possible 
candidate  for  evaluation  is  "Asynchronous  Task  Signalling”. 

3.1.6  Chapter  13 

Issue/Problem  Definition:  Many  of  the  features  in  Chapter  13  are  not  implemented  in 
current  commerdally  available  compilers  today. 

Backmund:  Chapter  13  of  me  Reference  Manual  for  me  Ada  Programming  Language  is 
titled,  "Representation  Qauses  and  Implementation-Dependent  Features”.  The  Ada 
Compiler  Validation  Capability  (ACVC)  test  suite  does  not  moroughly  test  features 
contained  in  this  chapter.  These  features  are  optional  and  merefore  a  cox^iler  can  have 
me  status  of  "validated”  wimout  any  of  mese  features  implemented.  However,  many  people 
feel  mat  Chapter  13  is  required  for  real-time  enmedded  applications. 

This  information  was  supplied  by  me  following  sources:  Project  Interviews,  ARTEWG  & 
SIGAda  Meetings,  Current  Software  Engineering  Literature,  and  LabTek  E^^rience. 

Anaiysis  Support.  There  is  an  inherent  dilemma  in  me  design  of  a  high-order  language 
wim  a  systems  progranunix^  capability.  On  me  one  hand  me  language  designers  are  trying 
to  achieve  reliability  by  raising  me  level  of  me  language.  For  example,  mey  provide  data 
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types  and  encourage  the  taking  of  an  abstract  view  of  objects,  in  which  they  are  known  only 
by  the  set  of  operations  applicable  to  them:  controUing  the  applicable  operations  enables 
incorrect  usage  to  be  detected.  On  the  other  hand,  systems  applications  require  the  ability 
to  stay  rather  close  to  the  machine,  and  not  only  for  reasons  of  efficiency.  For  example, 
defining  a  hardware  descriptor  must  be  done  in  terms  of  the  physical  properties  such  as  the 
bit  positions.  A  mapping  different  from  that  prescribed  by  the  hardware  would  not  merely 
be  inefficient  •  it  would  be  incorrect  and  would  not  work.  To  produce  a  correa  program  in 
such  cases  the  application  engineers  are  forced  to  abandon  the  abstract  view  and  to  work  in 
terms  of  the  ph^cal  representation.  This  contradiction  cannot  be  avoided.  The  language 
must  deal  with  objects  at  two  different  levels,  the  logical  and  the  representation  levei  [3]. 
That  is  the  purpose  of  Qiapter  13  of  the  Reference  Manual 

In  summary,  fifty  percent  of  the  projects  interviewed  reported  that  a  lack  of  Giapter  13 
features  implemented  in  their  version  of  the  compiler  posed  a  serious  problem. 

Problem  Resolution'.  (Short  Term)  As  mentioned  above  under  Validation,  Chapter  13 
features  must  be  tested  by  the  ACVC.  Consideration  should  be  given  to  making  the 
Chapter  13  features  mandatory  for  compilers  used  for  embedded  systems  development 
* 

32  Software  Development  Acdvides  and  Related  Tools 

Software  development  of  a  real-time  embedded  application  is  essentially  comprised  of  three 
major  phases  -  a  concept  definition  pha^  a  development  phase,  and  a  deployment  and 
operational  phase.  In  the  concept  definition  phase  (the  initiai  or  early  life-cyde  phase), 
requirements  are  identified,  an  intended  performance  envelope  is  stated  and  statements  of 
needs  are  written.  The  development  phase  primarily  consists  of  the  design,  code  and  test 
activities  concerned  with  the  system  implementation.  The  deployment  and  operational 
phase  consists  of  the  important  maintenance  and  suppon  activities  required  to  complete  the 
final  or  last  phase  of  the  life-^de.  [10] 

It  is  important  to  point  out  that  although  the  life-cyde  phases  imply  that  when  one  phase 
ends  the  next  phase  begins,  in  practice,  there  is  substantial  iteration  between  the  phases. 
For  example,  if  in  the  unplementacion  phase  a  discrepani^  is  apparent,  then  it  becomes 
necessary  to  go  back  to  the  design  phase  and  make  any  modifications  that  are  needed. 

Following  is  a  general  problem  resolution  whidi  covers  the  area  of  software  development 
and  related  too^  It  can  be  applied  to  most  of  the  subsections  under  section  32. 

Problem  Resolution:  (I^ng  Term)  The  proper  selection  and  use  of  tools  is  the  greatest  hope 
for  Improving  the  quwty  and  lowering  the  cost  of  developing  software.  Although  "software 
engineering  methodoioaes”  are  comteptually  the  answer  to  many  development  problems, 
experience  has  shown  mat  it  is  the  tools  that  drive  how  engineers  develop  software.  If  a 
methodology  is  embodied  within  a  tool  that  is  perceived  as  being  useful,  then  the 
methodology  will  be  followed,  bi  the  absence  of  such  tools,  to  get  large  groups  of  engineers 
to  all  use  the  same  methods  is  nearly  impossible.  For  this  reason,  the  development  of 
public  domain  software  tools  should  be  supported  to  the  maximum  degree  possible. 
Already  the  WIS  (WWMCCS  Information  System)  program  has  supported  the  development 
of  a  set  of  tools  through  the  Naval  Ocean  S^tems  tenter.  These  tools  have  been  placed  in 
the  Ada  repository  on  the  MQ.-NET  at  SIMT1E12D  and  are  available  to  US  corroratioos. 
Although  these  tools  are  not  yet  production  quality,  there  are  efforts  underway  to  mnd  their 
upgradmg  and  maintenance.  This  activity  should  receive  the  full  support  of  the  services.  It 
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may  be  possible  to  set  up  a  program  whereby  tools  that  are  taken  from  the  repository 
improved  by  users  can  be  repurchased  by  the  government  to  place  the  inmroved  version 
back  into  the  repository.  This  would  provide  the  best  of  both  "commercial  on  the  shelf  and 
"government  ownership"  approaches  to  providing  software  for  government  projects. 

The  following  sections  apply  to  the  general  problem  resolution  of  tool  development: 

reference  section  32.1,  "Requirements  Analysis" 

reference  section  32. 1. 1,  "I^id  Prototyping" 

reference  section  32.12,  "Requirements  Tracing" 

reference  section  322,  "Configuration  Management" 

reference  section  323,  "Design" 

reference  section  322.1,  "Flow  Dianains" 

reference  section  3222,  "Program  Design  Language  (PDL)" 

reference  section  32.4,  "Documentation" 

reference  section  322,  "Implementation" 

reference  section  32.6,  "Integration" 

reference  section  32.6.1,  "Debuners" 

reference  section  32.62,  "Simulation" 

reference  section  32.62,  "Automatic  Regression  Testing" 

reference  section  32.6.4,  Test  Verification  Matrix" 

reference  section  32.62,  Test  Generation  Assistance" 

reference  section  32.7,  "Maintenance" 


32.1  Requirements  Analysis 

Issue/Problem  Definition:  Several  tools  exist  to  help  identify  the  requirements  of  a  software 
system.  However,  these  tools  do  not  always  integrate  well  with  the  other  support  tools  for 
requirements  tracing  and  configuration  management. 

Background:  Requirements  are  precise  statements  of  need  intended  to  cqi^ey 
understanding  about  a  desired  result.  They  describe  the  external  char^eristics,  or  visible 
behavior  of  the  result,  as  well  as  constraints  such  as  performance,  reli^ility,  s^ety  and  cost. 
Analysis  is  the  systematic  process  of  reasoning  about  a  problem  and  its  constituent  parts  to 
understand  what  is  needed  or  what  must  be  done.  [8] 

The  requirements  analysis  process  defines  the  system's  functional  requirements  (functions, 
inputs,  outputs),  external  interfoce  requirements  (e.g.  user  interfiice),  and  performance,  and 
other  requirements  such  as  security,  [u] 

This  information  was  supplied  the  foUowiim  sources:  ARTEWG  &  SICAda  Meetings, 
Current  Software  Engineering  Literature,  and  LabTek  Experience. 

Anafysis  &.  Support:  Some  of  these  tools  require  specialized  hardware  to  suppon  graphics 
intenaces  which  are  used  to  help  visualize  the  structure  of  the  software.  Often  the  tools  ve 
cumbersome  to  use,  and  because  no  standard  exists,  training  is  a  major  problem  with  using 
the  tools  and  the  documentation  that  they  generate.  These  problems  are  largely  language 
independent  Hierefore  the  only  impact  related  to  Ada  is  the  trend  towards 
standardization. 
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In  summaiy,  the  capturing  of  requirements  is  language  independent  The  problems  arise 
because  there  are  tools  for  each  aspect  of  software  development  and  these  tools  are  not 
integrated  to  work  well  together. 

Problem  Resolution:  (Long  Term)  If  tools  can  be  developed  in  Ada  for  use  in  many 
development  environments,  then  the  availability  of  common  reqturements  definition  tools  is 
a  likely  by-product 

Also  see  the  general  problem  resolution  under  "Software  Development  Activities  and 
Related  Tools"  above. 

32.1.1  Rapid  Prototyping 

Issue/Problem  Definition:  The  Ada  language  does  not  directly  support  rapid  prototyping. 

Back^und:  Software  prototyping  is  a  process  (the  act  stu^,  or  skill)  of  modelling  user 
requirementr.  in  one  or  more  levels  of  detail,  including  working  models.  Project  resources 
are  allocated  to  produce  scaled  down  versions  of  the  software  described  requirements. 
The  prototype  version  makes  the  software  visible  for  review  by  users,  designers  and 
management  This  process  continues  as  desired,  with  running  versions  ready  for  release 
after  several  iteratioas.  [IS] 

This  information  was  supplied  the  following  sources:  ARTEWG  &  SIGAda  Meetings, 
Current  Software  Engineering  Literature,  and  LabTek  Experience. 

Analysis  <&  Support:  Ada  is  designed  to  sup^rart  large  applications  where  the  interfaces 
between  the  modules  must  be  rigidlv  defined  in  advance  of  their  use.  Ada  forces  users  to 
"think  before  they  code",  winch  is  beneficial  for  application  code  development,  but  not 
always  expedient  for  rapid  protor^ing.  When  Ada  mterfaces  change,  the  impact  ripples 
back  to  ail  units  using  toose  interraces.  This  makes  dofwn-stream  changes  to  the  code  less 
than  "rapid".  Since  the  nature  of  rapid  protoQ^ing  is  to  flush  out  different  design  ideas,  the 
design  and  code  tends  to  iterate  on  a  week  by  week  basis. 

In  summary,  the  rapid  prototyping  that  is  discussed  here  is  the  "throw-away”  type.  It  is 
generally  used  to  obtain  information  on  system  perfomiance,or  to  test  certain  design  ideas, 
and  is  discarded  after  it  has  served  its  pux^pose.  As  pointed  out  above,  this  process  may  not 
be  as  rapid  in  Ada  as  some  other  languages. 

Problem  Resolution:  (Woric-Around)  The  overhead  in  modifying  the  Ada  interfaces  must  be 
reduced  in  order  to  prevent  this  activity  from  consuming  an  inordinate  amount  of  time. 
Clever  reuse  of  packages,  espedaily  generics  may  help  alleviate  this  problem  to  some 
degree.  Fast,  interpretative  Ada  environments  can  alw  make  the  design  changes  less 
painfiiL  Since  rapid  prototypes  tend  to  be  small  in  comparison  to  the  applicanon,  the 
difficulties  in  using  Ada  to  do  r^id  prototyping  can  be  managed. 

Also  see  the  general  problem  resolution  under  "Software  Development  Activities  and 
Related  Tools”  above. 

32.12  Reqnirements  Tracing 
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Issue/Problem  Definition:  Requirements  tracing  is  not  new  to  Ada,  and  is  only  included 
here  for  completeness. 

Backhand:  Requirements  tracing  is  the  practice  of  providing  a  documented  allocation  of 
requirements  from  the  highest  level  speafication  down  to  the  code  section  that  satisfies 
those  requirements.  This  is  done  to  provide  a  measure  of  assurance  that  all  of  the 
requirements  have  been  met  and  tested.  It  is  also  useful  when  requirements  change,  and  it 
becomes  necessary  to  re-evaluate  portions  of  a  program  for  impact.  If  requirements  are 
eliminated,  then  those  code  sections  may  be  able  to  be  reduceo  or  removed  entirely.  In 
cases  where  new  requirements  are  added  or  "clarified",  the  related  code  sections  can  be 
found  quicldy  (in  theory)  and  be  updated. 

This  information  was  supplied  1^  the  following  sources:  ARTEWG  &  SIGAda  Meetings, 
Current  Software  Engineering  Literature,  and  LabTek  Experience. 

Anaiysis  <k  Support:  The  standardization  of  Ada  as  a  PDL  (program  design  language)  and 
as  an  implementation  language  does  make  tool  generation  to  support  requirements  tracing 
through  these  phases  more  practical.  Standard  requirements  keywords  within  the  PDL  can 
serve  multiple  purposes.  If  the  C5  level  specifications  are  automatically  generated  from  the 
PDL  this  provides  an  input  into  that  documentation.  Since  the  Ada  code  can  be  included 
within  the  same  file  as  the  PDL,  the  same  keywords  provide  traceability  down  to  the  code 
sections. 

In  summary,  requirements  tracing  can  be  facilitated  by  Ada.  If  Ada  is  used  as  the  PDL  and 
as  the  implementation  language,  the  generation  of  this  requirements  tracing  tool  becomes 
easier. 

Problem  Resolution:  (Long  Term)  Work  needs  to  be  done  to  help  link  the  high  level 
specifications  to  the  PDL. 

Also  see  the  general  problem  resolution  under  "Software  Development  Activities  and 
Related  Tools"  above. 

222  Configuration  Management 

Issue/Problem  Definition:  Difficulties  exist  because  of  a  lack  of  commonality  of  tools. 

Background:  A  configuratioa  item  is  a  collection  of  hardware  or  software  elements  treated 
as  a  unit  for  the  purpose  of  configuration  management.  Configuration  Management  (CM) 
is  the  process  of  identifying  and  defining  the  coimguration  items  in  a  system,  controlling  the 
release  and  chaxige  of  these  items  throughout  the  system  life  cycle,  recording  and  reporting 
the  status  of  conneuration  items  and  change  requests,  and  verifying  the  completeness  and 
correctness  of  configuration  items.  [11] 

This  information  was  sroplied  by  the  following  sources:  Current  Software  Engineering 
Literature,  and  LabTek  ucperience. 

Anaiysis  &  Support:  Tools  that  process  Ada  source,  such  as  the  Ada  compiler  or  PDL 
processor  frequently  maintain  their  own  library  of  compilation  units.  This  library  usually 
contains  a  variety  of  file  formats,  and  problems  may  arise  when  attempting  to  place  the 
library  under  configuration  management.  Since  the  library  can  theoretically  w  regenerated 
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by  reprocessing  the  Ada  source  code.  Typically  only  the  source  code  is  placed  under 
configi^tion  management  This  is  generally  sausfactoiy  provided  that  a  mechanism  exists 
to  verify  that  the  same  command  line  options  are  used  to  invoke  the  tools.  Ideally  the 
entire  library  should  be  placed  under  CM  tor  each  major  release. 

Some  tools  are  only  available  on  graphics-based  workstations,  while  the  compiler  may  only 
be  avmlable  on  a  mainframe  computer.  Maintaining  consistent  versions  of  all  development 
materials  can  be  extremely  tedious  under  these  circumstances.  Some  tools  allow  conversion 
of  internal  file  formats  to  less  eflSdent  printable  ASCII  formats.  This  facilitates  placing  ail 
configuration  items  into  a  common,  machine  readable  database. 

In  summary,  tools  for  different  phases  of  the  software  life-cycle  are  often  made  by  different 
vendors,  so  they  are  not  usually  integrated  with  each  other.  This  has  always  been  a 
problem. 

Problem  Resolution:  See  the  general  problem  resolution  under  "Software  Development 
Activities  and  Related  Tools"  above. 

3.2J  Design 

Issue/Problem  Definition:  Designing  a  system  in  Ada  is  not  seen  to  be  a  problem.  However, 
the  time  required  to  design  a  system  in  Ada  is  significant  and  must  not  be  overlooked 
(especially  if  training  of  personnel  is  needed). 

Background:  Design  is  the  process  of  applying  various  techniques  and  principles  for  the 
purpose  of  defining  a  device,  a  process,  or  a  system  in  sufficient  detail  to  permit  its  physical 
realization. 


This  information  was  supplied  by  the  following  sources:  Projea  Interviews,  and  LabTek 
Experience. 

Ar  aiysis  Jc  Support:  Ada  facilitates  the  design  process.  Once  the  design  is  captured  in  an 
Ada  PDL  (Program  Design  Language),  Ada  consistency  checking  Mips  to  verify  the 
meeting  of  design  requirements. 

Problem  Resolution:  (Short  Term)  The  design  phase  can  be  improved  by  the  following 
recommendation:  Managers  should  modify  their  schedules  to  allow  more  time  in  the 
beginning  of  the  development  phase  for  sofbvare  definition.  Ada  designs  generally  develop 
slowly  but  the  coding  and  debuggi^  phases  tend  to  proceed  more  smoothly  (provided  the 
are  adequate).  Also,  there  is  a  need  to  provide  better  guidelines  for  use  of  an  Ada 

(Long  Term)  There  is  soil  a  need  for  design  methodologies  and  tools  that  help  to  capnire 
software  requirements  in  a  format  suitable  for  an  Ada  mmlementation  and  to  propagate 
these  requirements  in  a  form  suitable  for  input  into  the  PDL  processor.  One  of  the  most 
difficult  areas  in  systems  design  of  DoD  projects  is  the  constant  changing  of  requirements. 
Tools  are  necessary  to  help  lessen  the  impact  of  this  problem  in  Ada  software  systems. 

Also  see  the  general  problem  resolution  under  "Software  Development  Activities  and 
Related  Tools"  above. 
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32J.1  Flow  Diagrams 

Issue/Problem  Definition:  Problems  associated  with  generating  and  interpreting  flow 
diagrams  are  not  unique  to  either  Ada  or  real-time  programs,  and  are  only  included  here 
for  completeness. 

Background:  Flow  diagrams  are  used  to  graphically  depict  the  data  flow  and  control  flow  of 
programs.  These  graphic  representations  help  convey  the  operation  of  programs  so  that 
high  level  interpretations  can  be  made  in  a  relatively  short  time. 

This  information  was  supplied  the  followiiu  sources:  ARTEWG  &  SIGAda  Meetings, 
Current  Software  Engineering  Literature,  and  LabTek  Experience. 

Analysis  &.  Support:  Flow  diagrams  are  mentioned  here  for  completeness,  and  to  suggest 
that  the  transportability  of  Ana  based  tools  make  the  development  of  a  tool  that  could 
generate  flow  diagram  more  cost  effective.  Although  flow  diagrams  are  most  useful  during 
the  concept  deflidtion  phase  of  software  development,  they  are  often  helpful  during 
subsequent  phases  for  documentation  purposes.  Unfortunately,  due  to  the  difficulty  in 
generated  these  diagrams,  they  are  all  too  frequently  not  kept  up  to  date  with  the  design 
and  code. 

In  summary,  Ada  can  facilitate  the  generation  of  flow  diagram  tools,  due  to  its 
transportability. 

Problem  Resolution:  (Long  Term)  The  standardization  of  Ada  may  make  it  practical  to 
build  a  tool  that  would  automatically  generate  various  levels  of  flow  diagrams  from  the  Ada 
source  code.  This  would  provide  the  most  accurate  source  of  graphic  documentation  and 
would  benefit  those  maintaining  the  programs. 

Also  see  the  general  problem  resolution  under  "Software  Development  Activities  and 
Related  Tools"  above. 

3232  Program  Design  Language  (PDL) 

Issue/Problem  Definition:  PDL  issues  are  not  unique  to  real-time  applications,  or  Ada, 
except  for  the  possible  concern  about  restricting  some  Ada  features  in  tne  PDL  because  of 
execution  time  performance  penalties. 

Background:  Program  design  languages  are  used  to  provide  a  high  level  representation  of  a 
program  in  a  more  rigorous  fashion  than  either  natural  language  or  flow  diagrams.  With 
the  adoption  of  Ada  as  the  standard  basis  for  PDLs,  the  additioi^  features  of  being  able  to 
verify  interfaces  and  showing  dependencies,  become  available  simply  by  processing  the  PDL 
with  an  Ada  compiler. 

This  information  was  supplied  by  the  foUowii^  sources:  Project  Interviews,  ARTEWG  & 
SIGAda  Meetings,  Current  Softwve  Engineering  Literature,  and  LabTek  Experience. 

Analysis  &.  Si^port:  The  conflict  arises  when  Ada  is  being  used  for  both  the  PDL  and  the 
implementation  language.  There  is  a  concern  that  if  the  designer  stays  at  a  high  level  (as 
th^  should)  in  the  PDL,  that  the  implementor  will  use  an  inappropriate  construct  in  the 
code.  This  is  further  complicated  if  the  PDL  and  code  are  never  separated,  but  remain 
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within  a  single  file.  An  example  is  that  record  types  with  default  discriminants  may  be  ideal 
for  bemg  able  to  change  the  representation  of  input  buffers,  however,  due  to  the 
performance  issues  associated  with  this  construct,  it  is  probity  not  ideal  for  the 
implementation  code. 

Problem  Resolution:  See  the  general  problem  resolution  under  "Software  Development 
Activities  and  Related  Tools”  above. 


3.2.4  Documentation 

Issue/Problem  Definition:  Ada  tools  such  as  PDL  processors  daini  to  support  automatic 
generation  of  some  specifications  and  software  documentation.  To  a  large  degree,  the 
output  of  these  tools  is  somewhat  less  than  satisfactory  with  respect  to  being  complete. 

Background:  ^ftware  documentation  is  technical  data  or  information,  including  computer 
listings  and  printouts,  in  human-reackble  form,  that  describe  or  specify  the  design  or  details, 
expl^  the  capabilities,  or  provide  operating  instructioos  for  using  the  software  to  obtain 
desired  results  ft'om  a  software  system.  [11] 

This  information  was  supplied  by  the  following  sources:  ARTEWG  &  SIGAda  Meetings, 
Girrent  Software  Engineering  Literature,  and  LabTek  Experience. 

Analysis  <&.  Support:  The  output  of  these  tools  does  have  the  benefit  of  accurately  tracking 
^e  PDL,  and  thus  the  implementation.  This  is  important  since  when  changes  occur  in  the 
implementation,  they  are  mudi  more  likely  to  be  reflected  in  the  C5  level  specifications. 
The  quality  of  the  output  of  these  tools  is  highly  dependent  upon  the  correa  wording  of 
PDL  Traming  is  necessary  to  assist  POL  developers  so  that  the  output  is  complete  and 
consistenL 

Problern  Resolution:  (Long  Term)  As  alw^rs,  the  ability  to  generate  quality  graphics  and 
text  is  important  to  the  comprehension  of  design  information.  Many  tools  can  support  large 
documents,  or  graphics,  but  not  both.  Even  when  the^  support  both,  they  may  not  work  well 
with  the  configuration  management  tools.  Since  Ada  is  bemg  recommended  as  the  standard 
PDL,  this  helps  to  lend  st^^port  to  tool  development  to  process  PDL  for  documentation 
support  Work  is  needed  to  provide  integration  among  interacting  tools. 

Also  see  the  general  problem  resolution  under  "Software  Development  Activities  and 
Related  Tools”  above. 

3.2J  Implementation 

Issue/Problem  Definition:  The  improper  use  of  Ada  features  can  create  performance 
problems  in  an  implementation. 

Background:  The  implementation  phase  is  the  period  of  time  in  the  software  life  cycle 
during  which  a  softie  product  is  aeated  from  a  design  document  and  debugged.  [11] 
Although  the  diagi^  of  a  software  life  ^cie  commonly  shows  phases  following  sequentially 
from  each  other,  in  actuality  it  is  usually  necessary  and  desi^ie  to  have  some  iteration 
between  them.  In  addition,  there  is  often  significant  overlap  between  phases.  [13]  A  good 
background  in  software  engmeering  practices  is  probably  necessary  to  use  the  full 
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capabilities  of  the  language  •  simply  teaching  professional  programmers  Ada  is  not  enough. 
[12] 

This  information  was  supplied  by  the  following  sources:  Projea  Interviews,  and  LabTek 
Experience. 


AncUysis  &  Support:  Although  support  tools  are  needed  in  all  phases  of  software 
development  they  are  discussed  briefly  under  "Implementanon”  because  historically  this  is 
the  phase  that  has  been  most  influenced  by  tools.  Support  tools  include  the  compilation 
systems,  editors,  assemblers,  linkers,  locators,  loaders,  librarians,  pretty-printers,  etc.,  that 
allow  an  engineer  to  input  source  code  ami  generate  executable  machine  code.  Software 
suppon  tools  are  also  needed  for  debugging,  configuration  management,  documentation 
generation,  PDL  processing,  rapid  prototyping,  simulation  and  test  support.  The  acquiring 
of  a  good  toolset  is  important  for  the  success  of  a  project,  and  can  reduce  software 
development  time  significantly.  Editors,  assemblers,  linkers,  locators,  loaders  and  librarians 
have  been  available  for  sometime  and  do  not  present  substantial  problems.  The  problems 
lie  in  the  immaturity  of  Ada  compilation  systems,  and  the  lack  of  debuggers  and  other 
suppon  tools  for  them. 

In  summary,  when  implementing  an  Ada  design  for  a  real-time  embedded  system,  care 
should  be  taken  to  insure  that  the  appropriate  Ada  constructs  are  used,  and  that  the  code 
generated  by  the  implementation  does  not  require  excessive  time  to  execute. 

Problem  Resolution:  (Short  Term)  It  is  hoped  that  a  software  engineer  will  study  the 
problem  and  language  constructs  sufficiently  before  implementation  to  decide  what  feamres 
of  the  language  should  be  used  to  best  handle  the  problem  at  band. 

• 

Also  see  the  general  problem  resolution  under  "Software  Development  Activities  and 
Related  Tools”  above. 


32.6  Integration 

Issue/Problem  Definition:  No  problems  specific  to  Ada  have  been  identified  in  this  area  and 
this  section  has  been  included  only  for  completeness. 

Background:  Integration  is  the  process  of  combining  software  elements,  hardware  elements, 
or  both  into  an  overall  system,  [ll] 

This  information  was  supplied  by  the  following  sources:  Project  Interviews,  Current 
Software  Engineering  literature,  and  LabTek  E^rience.  Reference  section  4  for  the 
Issue  Vs.  Source  Matiu 


Anatysis  &  Support:  In  Ada,  integration  generally  proceeds  more  rapidly  partially  due  to  its 
strong  typing  mechanism.  Many  errors  that  typic^y  would  not  be  cau^t  until  execution 
time  m  other  languages  are  often  caught  at  compilation  time  in  Ada.  [7] 

Problem  Resolution:  See  the  general  problem  resolution  under  "Software  Development 
Activities  and  Related  Tools”  above. 
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32.6.1  Debuggers 

Issue/Problem  Definition:  Current  in<ircuit  emulators  operate  (at  best)  as  spibolic 
debuffiers,  and  have  no  provisions  to  support  real-time  momtoring  of  dynamically  allocated 
variables. 

Backg^und:  Debugging  refers  to  the  process  of  removing  errors  from  computer  programs. 
Although  debugging  can  and  should  be  an  orderly  process,  it  is  still  very  much  practiced  as 
an  art  A  software  engineer,  evaluating  the  results  of  a  test  is  often  confronted  with  a 
symptomatic  indication  of  a  software  problem.  That  is,  the  external  manifestation  of  the 
error  and  the  internal  cause  of  the  error  may  have  no  obvious  relationship  to  one  another. 
The  poorly  understood  mental  process  that  connects  a  symptom  to  a  cause  of  a  software 
problem  is  debuggii^  [9] 

A  debugging  approach  can  be  supplemented  with  debugging  tools  (often  called  debuggers). 
Debuggers  are  available  in  a  wide  variety,  the  most  useful  being  dynamic  debugging  aids 
and  automatic  test  case  generators.  Memory  dumps  and  cross  reference  maps  also  aid  the 
debugging  process. 

This  information  was  supplied  by  the  following  sources:  Project  Interviews,  and  LabTek 
Experience. 

Anafysis  Suppofr.  An  in-drcuit  emulator  (ICE)  allows  code  to  be  traced  as  it  is  executed 
without  intenering  with  the  real-time  nature  of  it  That  is,  an  ICE  is  a  hardware 
substitution  of  the  processor  winch  supports  real-time  monitoring  of  the  processor’s 
activities.  Emulaton  generally  have  capabilities  to  halt  execution  on  user-programmable 
events,  such  as  a  write  to  a  specified  memoiy  address.  When  the  event  occurs,  a  halt  is 
generated,  and  the  user  has  the  ability  to  examine  the  previous  instructions  that  lead  up  to 
the  event  (trace-back).  This  type  of  feature  makes  it  possible  to  detect  design  errors  that 
cause  data  to  be  corrupted  by  incorrect  memoiy  writes. 

One  of  the  side  benefits  of  emulaton  is  their  ability  to  emulate  the  memoiy  of  the 
embedded  system,  and  thus  relieve  the  necessity  to  continually  program  new  PROMs 
(ihogramxnaole  Read-Only  Memories).  The  emulator  uses  its  readT/write  memory  to 
substitute  for  the  PROM,  tmis  the  process  of  loading  a  program  for  execution  much 

faster.  Emulaton  also  provide  capabilities  to  profile  program  execution,  which  aids  in 
determining  which  code  sections  should  be  optimized. 

Current  emulaton  operate  (at  best)  as  symbolic  debuggers.  This  implies  that  the  user  has 
the  ability  to  access  certain  "symbols"  su<m  as  variable  names,  subpro^am  names,  etc.  The 
symbol  tables  are  generated  by  the  compiler  or  assembler  and  provided  to  the  emulator, 
usually  along  with  me  binaiy  code  througn  a  down  loading  process  over  a  data  link.  What  is 
mining  is  the  ability  to  operate  on  a  source  code  level  with  emulators.  Ideally,  the  user 
could  specify  a  source  statement  Hne  number  at  which  the  program  should  halt,  and  when 
the  program  does  halt,  have  the  same  namity  conventioiis  and  scope  (possibly  extended)  of 
the  program  at  that  point  in  its  execution.  Si^e  stepping  of  the  progr^  at  the  Ada  source 
level  is  an  extremely  useful  feature  when  trying  to  isolate  difRqiit  de^gn  erron.  Often  the 
hardware  is  new,  and  it  operates  either  incorrectly,  or  in  a  way  that  is  not  reflected  in  the 
documentation.  By  stoppmg  program  execution  at  the  points  at  which  it  interacts  with  the 
hardware,  the  user  can  qmci^  locate  causes  of  failure.  By  not  supporting  source  level 
operation,  the  Ada  programmer  is  often  forced  to  study  the  generatra  assembly  language 
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code  in  order  to  resolve  where  to  set  break  points,  or  to  examine  memory.  This  can  be 
extremely  tedious  in  situations  where  extensive  optimization  has  been  done  on  the 
generated  code.  Register  assignments  are  not  always  obvious  and  reordering  of  the  code 
can  be  very  confusing. 

Software  debuggers  are  tools  that  support  debugging  without  the  aid  of  external  hardware. 
Software  debuggers  on  the  other  Imd,  do  insert  code  into  the  executable  module  to 
produce  a  debugging  version.  Thus  the  debugging  version  and  the  real-time  version  are  not 
the  same  executable  modules.  The  overhead  of  a  software  debugger  is  usually  not  incurred 
with  an  ICE.  Several  manufacturers  now  provide  powerful  software  debuggers  that  provide 
source  level  debugging.  The  application  code  is  loaded  into  the  target  along  with  a  debug 
suppon  module,  module  provides  a  communications  interface  to  the  host  computer 
and  the  capability  to  set  break  points  and  examine  memory.  The  user  communicates 
directly  to  me  host  computer  via  a  standard  video  terminaL  Ine  host  commuter  is  in  turn 
cotmected  to  the  target  system.  All  communications  between  the  user  ana  the  target  are 
routed  through  the  host  computer  debug  support  software.  This  allows  the  user  intertace  to 
be  very  complex,  including  source  level  single  stepping,  yet  the  software  loaded  into  the 
target  is  very  simple,  keeping  it  small.  The  main  drawbar  is  the  loss  of  a  trace-back  and 
setting  break  points  on  certam  types  of  events,  such  as  memory  writes  to  specific  locations, 
for  real-time  execudoa 

In  summary,  what  is  desired  for  debugging  is  an  in-drcuit  emulator  with  me  features  of 
advanced  software  debuggers,  such  as  source  level  operations. 

Problem  Resolution:  (Long  Term)  An  emulator  that  supports  a  source  level  debugger  would 
provide  me  ability  to  trace  a  particular  variable^  procedure,  etc^  in  real-time.  Tools  to 
support  in-circuit  emulation  are  provided  by  third  party  vendors  (Le.  not  me  compiler 
vendor),  and  the  changes  made  in  compilers  are  not  supported  immediately  by  me  mird 
party  vendors.  Harch^e  changes  in  me  emulators  may  be  necessary  to  support  the 
dynamic  nature  of  objects  in  Ada.  For  example,  setting  break  points  normally  requires 
specifying  a  particular  address  (or  range  of  admesses)  wim  me  emulator.  However,  since 
storage  for  aata  within  procedures  is  allocated  and  deallocated  dynamically  at  execution 
time  of  me  procedure,  it  is  impossible  to  know  the  exact  memory  address  of  me  data  prior 
to  invoking  me  procedure,  mat  may  be  required  is  me  ability  to  establish  an  "arm" 
capability  which  detects  entering  a  si;^rogra^  and  can  calculate  a  data  frame  ofrset 
address  at  that  time  and  set  a  break  point  based  on  that  address.  When  me  subprogrm  is 
exited  (for  any  reason)  me  break  point  must  be  disarmed,  since  me  memory  address  will  be 
reused  by  me  next  subprogram. 

The  next  generation  of  microprocessors  appear  to  be  beipii^  to  resolve  this  problem.  They 
expect  to  be  operating  above  me  30MHz  mark  where  priding  emulators  is  unlikely  to  be 
practical.  The  industry  speculation  is  that  new  processors  will  contain  on-chip  logic  to 
provide  some  of  foe  features  currently  provided  ay  emulators.  In  mese  environments,  me 
debuggers  are  likely  to  be  software  driven. 

Also  see  the  general  problem  resolution  under  "Software  Development  Activities  and 
Related  Tools"  above. 

3.2.62  Simulation 
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Issue/Problem  Defyiition:  Simuladon  poses  no  new  additional  problems  with  respect  to  the 
Ada  language.  It  is  included  here  only  for  completeness. 

B<Kkgmund'.  In  software  test  environments,  simulation  is  used  to  substitute  for  the  real-life 
environment  in  which  ±e  application  wUl  operate.  Often,  various  elements  of  the  hardware 
are  not  available  at  the  begmning  of  software/Wdware  integration,  and  it  is  necessary  to 
simulate  not  only  the  external  events,  but  pieces  of  the  system  as  well  One  of  the 
advantages  in  usmg  simulators  is  that  usualfy  they  provide  additional  control  over  the 
environmental  events  that  can  not  be  achieved  with  the  real  system.  For  example,  it  may  be 
impossible  to  test  a  helicopter  at  Mach  4,  however  simulators  may  allow  the  generation  of 
data  and  events  to  test  the  software  under  the  conditions  that  would  be  present  if  the 
helicopter  could  achieve  Mach  4  flight.  Simulatois  also  assist  in  support  of  automatic 
testing  Programmable  simulators  can  be  set  up  to  provide  a  scenario,  and  test  support 
equipment  can  collect  the  responses  of  the  softv^e  bemg  tested.  In  this  way  many  tests  can 
be  run  in  a  much  shorter  time  than  what  would  be  requirra  to  run  real  operational  tests. 

This  information  was  supplied  by  the  followii^  sources:  Project  Interviews,  and  LabTek 
Experience. 

Anafysis  di  Support:  The  obvious  drawback  of  simulators  is  the  accuracy  to  which  they  can 
simulate  the  real  world  events.  Many  simulators  have  the  capability  to  playback  recorded 
real  world  events  that  were  logged  during  real  operational  missions  or  tests.  This  allows 
recreation  of  Guilts  that  are  otherwise  extremely  difficult  to  isolate  and  repw.  Even  so,  it  is 
almost  impossible  to  recreate  the  exact  actual  environment  Little  details  such  as  clock 
rates  that  vary  slightly  over  time  can  cause  an  interrupt  to  be  handled  at  a  different  time 
during  playback.  Once  the  responses  of  the  computer  change,  it  becomes  extremely 
difficmt  for  the  simulator  to  compensate  and  to  adjuk  the  playback  data  to  correa  for  the 
altered  behavior. 

The  degree  of  accuracy  of  a  simulator  directly  effects  its  usefulness.  It  also  usually  effects 
the  cost  of  the  simulator.  That  is,  simulators  that  do  not  accurately  reflect  the  operation  of 
the  real  system  can  do  more  damage  than  good,  and  simulators  that  very  accurately  reflea 
the  real  system  tend  to  be  very  costfy  to  buiul. 

In  siunmaiy,  with  the  transportability  of  Ada,  it  is  now  sometimes  easier  to  implement  a 
simulator,  since  the  operational  code  that  would  normally  drive  the  real  system  can  now  be 
transported  to  a  sinnuator  with  less  effort  in  many  cases.  In  this  way,  pieces  of  incomplete 
hardware  can  be  substituted  for  by  computers  nmning  the  same  code  that  the  real 
hardware  will  nm.  This  does  not  help  solve  the  (perhaps  more  diffioilt)  problem  of  real 
world  environment  simulation,  but  since  the  proliferation  of  microprocessors  is  so 
pervasive,  many  computers  within  weapons  systems  dedicate  a  large  percentage  of  their 
control  software  to  gntnTmimearintm  with  Other  computers,  and  therefore  a  corresponding 
percentage  of  the  software  be  tested  twing  a  computer  to  sirmiiate  the  communications. 

Problem  Resolution:  A  problem  resolution  is  not  required  here. 

See  the  general  problem  resolution  under  "Software  Development  Activities  and  Related 
Tools"  above. 
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3.2.63  Automatic  Regression  Testing 

Issue/Pvtlem  Definition:  Automatic  Regression  Testing  poses  no  new  additional  problems 
due  to  the  Ada  language.  It  is  included  here  only  for  completeness. 

Back^und:  Regression  testing  is  the  selective  retesting  to  detect  faults  introduced  during 
modification  of  a  system  or  a  system  component,  to  verify  that  modifications  have  not 
caused  unintended  adverse  effects  or  to  verify  that  a  modifi^  system  or  system  component 
still  meets  its  specified  requirements.  [11] 

This  information  was  supplied  by  the  following  sources:  Current  Software  Engineering 
Literature,  and  LabTek  Experience. 

Anafysis  <&  Support:  The  process  of  regression  testing  often  consumes  a  substantial  ponion 
of  the  effort  for  large  applications  that  undergo  many  releases  over  their  lifetime.  In  the 
absence  of  proper  tools,  regression  testing  is  frequently  incomplete  and  therefore  it  is  not 
uncommon  to  have  softv^e  regress.  That  is,  in  the  release  that  fixes  one  error,  other  errors 
are  introduced  in  functions  that  previously  worked  correctly.  Most  development 
environments  do  not  have  adequate  mcilities  to  automatically  capture  and  re-run  tests  that 
were  used  to  verify  the  initial  system  capability. 

In  summary,  the  transportability  of  Ada  may  provide  the  foundation  upon  which  testing 
tools  can  be  developed  and  provided  to  a  wide  ffoup  of  contraaors.  The  major  difficulty  is 
the  intimate  interfaces  required  to  drive  simt^ors  in  support  of  the  testmt  Since  the 
simulators  often  operate  in  real-time  the  interfaces  are  often  customized  to  a  large  degree. 
Provisions  must  be  made  within  automatic  testing  tools  to  allow  reconfiguration  and 
customization  of  these  interfaces. 

Problem  Resohitian:  See  the  general  problem  resolution  under  "Software  Development 
Activities  and  Related  Tools"  above. 

3.2.6.4  Correlation  to  Specified  Test  Verification  Matrix 

Issue/Problem  Definition:  No  additional  problems  are  imposed  by  the  use  of  the  Ada 
language  with  respect  to  correlation  to  the  specified  test  vemcation  matrix.  It  is  included 
here  omy  for  completeness. 

Background:  A  traceability  matrix  maps  the  software  modules  to  the  requirements.  Each 
module,  in  tun,  must  h^  a  test  to  show  that  it  meets  the  requirements  and  a  test 
verification  matrix  can  be  constructed.  If  a  module  is  discovered  which  cannot  be  matched 
to  a  requirement,  then  that  discrepancy  should  be  resolved  by  eliminating  the  module  or 
updating  the  matrix.  [16] 

This  information  was  supplied  by  the  following  sources:  Current  Software  Engineering 
Literamre,  and  LabTek  u^rience. 

Anafysis  &  Support.  Typically  the  verification  matrix  is  not  machine  processable  other  than 
through  a  document  formaner.  A  need  exists  to  have  the  verification  matrix  be  generated 
automatically  from  the  raw  input  to  the  specifications,  and  to  have  a  form  of  the  matrix  be 
used  with  the  automatic  test  tools  to  insure  that  each  test  is  verified.  Use  of  specialized 
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comments  within  the  raw  (pre-formatted)  text  of  specifications  can  identify  the  mandated 
requirements  and  also  which  test  phases  and  how  they  will  be  verified. 

Itt  summary,  the  use  of  Ada,  and  standard  software  development  guidelines 
(DoD-STD-2167A)  should  facilitate  the  development  of  tools  to  process  the  specification 
documents  and  provide  the  above  capabilities. 

Problm  Resolution:  See  the  general  problem  resolution  under  "Software  Development 
Activities  and  Related  Tools"  above. 

32.6J  Test  Generation  Assistance 

Issue/Problem  Definition:  There  are  no  new  problems  associated  with  test  generation 
assistance  due  to  the  Ada  language.  It  is  included  here  onfy  for  completeness.  However, 
tools  that  generate  test  cases  need  to  be  more  complex  to  support  the  parsing  of  Ada 
programs  unless  they  operate  mom  an  intermediate  representation  of  the  source  Ada 
program. 

Background:  Test  generation  assistance  is  a  software  tool  that  accepts  as  input  a  computer 
progr^  and  and  test  criteria,  generates  test  input  dsua  that  meet  these  criteria,  and, 
sometimes,  determines  the  expected  results.  [11] 

Testing  within  the  context  of  software  enmeering  is  actually  a  series  of  four  steps  that  are 

implemented  sequentially.  Initially,  tests  rocus  on  each  module  individually,  assuring  that  it 

functions  prowriy  as  a  unit,  hence  unit  testing.  Next,  modules  must  be  assembled  or 

integrated  to  form  the  complete  software  pac^e.  integration  testing  addresses  the  issues 

assodated  with  the  dual  problems  of  verification  and  assembly.  Finally,  validation 

requftements  (established  during  the  planning  phase)  must  be  tested.  Valiaation  testing 

^ovides  final  assurance  that  software  meets  ail  ftmcoonai  and  performance  requirements. 

The  last  step  fails  out  of  the  software  engfoeering  category  ana  into  the  computer  system 

engineering  categofy.  System  testing  verifies  that  all  elements  mesh  properly  and  that 

overall  system  function  and  performance  are  achieved.  [9] 

* 

This  information  was  sraplied  by  the  following  sources:  Current  Software  Engineering 
Literature,  and  LabTek  Bi^rience. 

Andysis  <i  Support.  Tools  already  exist  within  the  Ada  software  repository  which  will 
instrument  Ada  source  code  and  count  the  times  each  path  is  executed.  Although  this  is  not 
sufficient  for  many  real  time  systems  it  does  provide  a  baseline  for  verifying  that  each  path 
has  been  executed  This  can  be  a  benefit  to  see  if  the  test  generation  tool  is  providing 
sufficient  test  coverage  to  check  all  paths.  Additional  tools  are  required  to  assist  in 
producing  test  cases. 

In  summary,  this  issue,  like  many  other  areas  in  software  development  is  not  unique  to  Ada, 
but  may  benefit  from  the  common  support  of  Ada  for  tool  transportability. 

Problem  ResoluxU)n:Set  the  general  problem  resolution  under  "Software  Development 
Activities  and  Related  Tools”  above. 
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32.7  Maintenance 

hsue/Problem  Definition:  There  haven't  been  any  serious  problems  identified  in  this  area, 
largely  due  to  the  lack  of  longevi^  of  Ada. 

Background:  Software  maintenance  is  the  modification  of  a  software  product  after  delivery 
to  correct  faults,  to  improve  performance  or  other  attributes,  or  to  adapt  the  product  to  a 
changed  environmenL  [11] 

This  information  was  supplied  by  the  following  sources:  Project  Interviews,  current 
literature,  and  LabTek  Experience. 

Analysis  dt  Support.  Where  Ada  code  has  been  maintained  for  some  period  of  time,  three 
minor  issues  nave  arisen.  The  first  is  the  conversion  from  subset  compilers  to  validated 
compilers.  In  some  cases  features  available  in  the  subset  compilers  became  unavailable  in 
validated  compilers.  Also,  interpretations  of  the  language  reference  manual  have  changed 
slightly  effecting  the  validity  of  some  programs.  Tbese  issues  are  believed  to  be  very  short 
term,  aad  of  no  significant  consequence.  The  last  issues  that  has  been  discovered  by  most 
developers  when  working  on  projects  with  more  than  a  few  thousand  lines  of  code,  is  that 
the  Ada  USE  clause  should  not  be  specified  for  any  packages  other  than  those  predefined 
in  the  language.  The  reason  for  this  is  because  of  the  di£5culty  in  tracing  the  origin  of  the 
object  or  type  definitions.  Without  an  intelligent  editor,  it  is  extremely  hard  to  locate  which 
package  an  object  was  declared  in  when  many  context  (WITH)  clauses  are  used. 

Problem  Resolution:  The  general  problems  associated  with  maintenance  of  software  will 
benefit  by  the  greater  use  of  automatic  tools.  See  the  general  problem  resolution  under 
"Software  Development  Activities  and  Related  Tools”  above. 

33  Management  &  Policies 

The  following  sections  discuss  the  problems  encountered  by  management  in  preparation  of 
an  Ada  contract  Among  the  issues  concerning  mai^ement  are:  proposal  development 
resource  allocation,  software  reuse  policies,  and  training  of  personnel. 

33.1  Proposal  Development 

Issue/Problem  Definition:  SufGdent  time  and  analysis  is  not  always  spent  during  proposal 
development  especially  regarding  the  inq}act  of  usi^  Ada  for  the  first  time. 

Background:  The  complexity  and  size  of  software  systems,  and  their  role  in  weapon  systems 
has  been  increasing  dramatically  in  recent  years.  Many  contractors  do  not  fully  appreciate 
the  difficulties  associated  with  developing  the  software  for  these  more  complex  systems. 
When  little  or  no  experience  in  using  Ada  exists  within  a  compam,  the  tendency  is  to 
assume  that  Ada  is  simply  another  language  axtd  that  uying  it  will  have  no  impact  on 
development 

This  information  was  simplied  by  the  following  sources:  Cunent  Software  Engineering 
Literature,  and  LabTek  uqierience. 

Analysis  <&  Support.  Software  is  frequently  given  less  analysis  than  the  rarresponding 
hardware  components.  Estimation  of  the  development  effort  remaixis  largely  guesswork 
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and  prone  to  underestimadon.  The  impact  of  working  towards  impossible  schedules  that 
can  not  be  changed  until  they  become  absolutely  absurd  is  severe,  engineers  are  forced  to 
start  coding  prior  to  understanding  the  requirements,  let  alone  having  a  completed  design. 
A  tradeoff  must  be  made  between  legislating  the  time  it  takes  to  develop  a  program  and 
allowing  the  development  to  proceed  indefimteiy. 

Problem  Resolution:  (Short  Term)  Contractors  should  justify  their  use  of  Ada  and 
demonstrate  that  they  understand  the  impact  of  using  Ada  and  are  prepared  to  support  the 
transinon  to  Ada. 

(Short  Term)  The  proposal  phase  should  be  expanded  to  include  more  effort  on  analyzing 
the  software  complexity  ana  estimation  of  the  corresponding  development  activity.  The 
whole  process  of  providing  schedules  needs  to  be  smdiea 

332  Resource  Allocation 

Issue/Problem  Definition:  The  resources  for  an  Ada  project  are  quite  different  from  other 
software  efforts  and  this  must  be  taken  into  account. 

Backffouhd:  Resources  for  a  software  projea  include  computer  resources,  software 
resources,  and  human  resources. 

This  information  was  supplied  by  the  following  sources:  Project  Interviews,  and  LabTek 
Experience. 

Anafysis  <k  Support:  Additional  hardware  resources  are  required  for  development  due  to 
the  mere  size  of  the  compilers  and  mpport  tools.  Due  to  the  inter-dependendes  of  Ada 
program  units,  many  recompilations  impose  a  laner  workload  on  the  development  system. 
In  addition,  extra  human  resources  are  needed  to  deal  with  problems  assodated  with 
learning  and  using  new  tools. 

Problem  Resolution:  (Short  Term)  The  learning  curve  associated  with  a  completely  new, 
complex  tool  set  must  be  taken  into  account  during  proposal  and  early  planning  phases. 

(Short  Term)  Related  to  the  proposal  phase  above,  the  planning  of  what  personnel, 
conmuter  and  fadlify  resources  wUi  be  required  is  essentiaL  Contractors  should  be  given  a 
"lead'time”  that  notifies  them  at  least  thm  months  prior  to  when  work  is  to  begin,  to 
prepare  for  the  contract  Due  to  the  uncertainties  of  govemmem  contracts,  it  often 
happens  that  in  one  month  a  contractor  has  an  excess  of  software  engineers,  and  in  the  next 
month  they  have  a  reqimemem  for  two  hundred  more.  Even  when  it  is  possible  to  hire  the 
people,  preparing  facilides  for  them  is  often  a  tune  consuming  process,  especially  when 
security  issues  are  involved. 

(Shon  Term)  Managemem  within  many  DoD  contractors  needs  to  be  advised  of  reports 
that  indicate  improved  cost  effectiveness  of  providing  two^rson  office  environments  with 
terminals  and  work  tables  for  each  engineer.  It  is  astonishing  that  contractors  seem 
perfectly  willing  to  pay  consultants  more  man  what  the  United  States  Secretary  of  Defense 
makes,  and  yet  supply  them  with  a  small  desk  in  a  large  crowded  room  full  of  ringing 
phones;  then  expect  them  to  be  able  to  design  the  most  complex  software  system  in  the 
world. 
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333  Reusable  Software 

Issue^roblem  Definition:  Several  difficulties  arise  in  the  reuse  of  software,  including: 
locat^  the  software  for  reuse,  providing  documentation  that  is  compatible  with  the 
remainder  of  the  system,  leg^  and  financial  issues,  and  understanding,  modifying  and 
testing  the  software  to  operate  in  the  new  environment 

Backhand:  Software  reuse  is  the  extent  to  which  a  module  can  be  used  in  multiple 
applications.  Once  it  is  located,  it  must  be  understood.  Building  something  out  of  parts 
that  are  not  understood  is  difficult  (and  undesirable!).  This  is  especially  true  for  real-time 
software  where  the  timing  characteristics  are  determined  by  the  a^ysis  and  understanding 
of  a  program’s  operation. 

This  information  was  supplied  by  the  following  sources:  Project  Interviews,  Current 
Software  Engineering  Literature,  and  LabTek  Experience. 

Anafysis  <k  Support:  To  be  reusable,  a  software  routine  needs  to  fit  into  the  total  system: 
that  requires  much  more  than  just  the  program  code.  Documentation,  specifications,  design 
history,  test  plans  and  data,  and  all  the  other  things  required  of  the  total  system  must  be 
available  for  this  component  In  too  many  cases  me  work  of  finthng  and  reusing  is  more 
than  that  of  reinventing,  but  that  leads  to  a  world  where  everything  is  custom  made  and 
unique;  something  that  cannot  be  afforded  in  tody’s  large  systems.  [16] 

Probably  more  difficult  than  the  technical  issues  are  the  legal  problems  associated  with 
software  reuse.  Who  owns  the  software  components?  Who  is  responsible  for  their  correa 
behavior?  How  should  the  owners  be  compensated?  How  can  contractors  be  rewarded  for 
the  ultimate  savings  associated  with  software  reuse? 

Developi^  reusable  software  for  real-time  sj^tems  is  particularly  difficult  since  the 
optimizations  often  require  taking  advantage  ot  the  spedne  hardware.  Alsa  contraaors 
maximize  profit  when  developing  software  in  the  most  expedient  fashion,  rather  than 
pending  the  extra  effort  and  cost  to  design  it  for  reuse.  The  recipients  of  reuse  are  most 
likely  other  contractors,  and  not  necessarily  the  original  developer. 

Problem  Resolution:  (Short  Term)  Recent  discussions  with  the  STARS  (Software 
Technology  for  Adapt^le,  Reliable  Systems)  office  indicate  there  is  an  intention  to 
upgrade  and  expand  the  software  repository  on  SIMTEL20  (ARPANET).  The  majority  of 
this  software  however,  is  related  to  tools  and  not  real-time  sonware. 

(Short  Term)  Reusable  software  must  be  designed  for  reuse  in  mind.  This  implies  a  need  to 
know  what  variances  are  allowed  in  different  Ada  i^lementations  and  and  understanding 
of  the  concepts  of  Ada  packaging.  Also,  a  mechanism  must  be  developed  to  measure  the 
abilify  to  reuse  a  particular  piece  of  software  before  the  reuse  effort  begins.  This  will 
provide  a  level  of  confidence  that  the  reuse  effort  will  be  successftil  and  will  help  to 
eliminate  the  concerns  established  by  previous  attempts  at  reuse,  only  to  result  in  a  wasted 
effort  and  a  need  for  a  total  rewrite. 

(Short  Term)  There  is  a  need  to  provide  a  transportability  handbook  for  Ada  to  assist 
engineers  in  this  effort 
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(Long  Term)  The  government  lould  establish  a  poliw  that  rewards  contractors  for 
producing  software  that  is  reusacie  by  other  contractors.  This  is  contrary  to  their  natural 
tendencies  and  will  require  sul»tantial  wisdom  to  develop. 

3J.4  Training 

Issue/Problem  Deft^on:  In  addition  to  the  usual  Ada/Software  Engineering  training  that 
is  required,  there  is  a  general  lack  of  knowledge  about  Ada  runtime  environments  (RTEs) 
in  the  user  community. 

Background:  Ada  training  takes  on  several  forms  ranging  in  effectiveness  and  cosl  The 
forms  of  training  are:  on  the  job  training,  college  level  courses,  self-paced  video  tape 
lectures  and  computer  aided  instruction,  and  concentrated  two  or  three  week  courses  given 
by  professional  instructors.  It  is  generally  held  throughout  the  Ada  community  that  courses 
teaching  the  language  without  hands-on  programming  assignments  are  of  little  value. 

This  infonnatioa  was  supplied  by  the  following  sources:  Project  Interviews,  Current 
Software  Engineering  Literature,  and  LabTek  Experience. 

Anaiysis  A  Suppm:  Many  of  the  projects  interviewed  had  some  training  program,  but  they 
were  generally  less  than  three  weeks.  Untrained  or  improperly  trained  programmers  tend 
to  use  Ada  in  one  of  two  modes:  either  to  mimic  their  most  comfortable  programn^g 
language  (typically  FORTRAN),  or  to  go  to  the  other  extreme  and  use  every  possible 
feature  of  the  language,  often  in  places  that  are  inappropriate. 

Elegant  Ada  solutions,  like  tasking  and  generics  often  result  in  slower  and  larger  programs. 
If  sophisticated  features  of  the  Ada  la^i^e  are  used  when  they  are  not  necessary,  the 
application  will  usually  perform  poorly.  For  example,  tracking  ta^ets  by  creating,  an  Ada 
task  for  each  target,  r^er  than  using  an  array  of  records  and  a  loop,  will  most  likely  give 
unsatisfactory  results  in  a  si^e  processor  applicatioa  There  is  a  tendency  by  some  to  use 
the  most  "elegant”  Ada  solution  rather  than  designing  for  real-time. 

Interviews  indicated  that  some  problems  with  their  designs  did  not  appear  until  late  in  the 
development  In  retrospect  they  would  have  used  other  techniques  to  implement  their 
application  had  they  known  the  performance  impacts  of  the  chosen  technique. 

problem  Resolution:  (Short  Term)  This  problem  can  be  corrected  by  prop^  Ada  training. 
Careful  attention  must  be  given  to  make  sure  that  current  Ada  implementation  problems  do 
not  create  a  long  term  influence  on  the  programming  styles  however.  A  separation  must  be 
made  between  features  that  are  always  likely  to  be  less  ef&dem  than  those  that  are 
inef&dent  because  of  cnirenc  technology.  Since  Ada  is  new  to  many  programs,  the  need  for 
additional  trainmg  is  substaxitiaL  This  goes  beyond  simple  instruction  in  the  syntax  and 
semantics  of  Ada,  but  to  the  software  engineering  prindpies  that  are  supported  by  the 
language.  Managers  and  software  selection  groups  must  aJw  be  trained  in  Ada  technology. 
For  example,  users  are  often  mislead  by  status  ot  validation.  The  AJPO  seal  of  approval,  or 
"validatetr  status  of  a  compiler  should  not  be  interpreted  to  mean  that  the  compiler  is 
usable  for  all  applications. 

(Short  Term)  Proposals  that  indude  provisions  for  a  lar]^  number  of  Ada  software 
engineers  should  also  show  a  capability  to  train  their  staffl  This  must  indude  time  in  the 
schedule  specifically  set  aside  for  training.  A  percentage  (10%)  of  the  staff  should  have 
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Ada  experience  on  a  previous  project,  to  provide  on-going  support  and  training  in  Ada 
details  that  will  not  be  absorbed  during  classes. 

(Short  Term)  Contractors  and  Program  Managers  should  obtain  the  AJPO's  Catalog  of 
Resources  for  Education  of  Ada  Software  Engineering  (the  cReaSE)  available  through 
the  Ada  Iiiformation  Gearinghouse  (AdalC). 
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4.  Issue  Vs.  Source  Matrix 

The  issues  that  were  defined  in  the  text  are  tied  to  their  source  in  the  matrix  below.  The 
first  column  contains  the  issue  and  the  next  four  columns  contain  the  sources.  The  sources 
are:  interviews,  ARTEWG  &  SIGAda  meetings,  current  literature,  and  LabTek 
experience.  An  "X”  is  placed  in  the  box  to  indicate  the  sources  of  each  issue. 
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5.  Summaiy 

Issues  that  impa^  the  success  of  a  software  development  in  Ada  can  be  classified  into  three 
primary  categories:  Compilation  Systems,  Software  Development  Activities  &  Related 
Tools,  and  Management  and  Poliaes.  The  area  that  is  creating  the  most  difficulties  is 
compilation  systems.  Within  this  category,  Ada  Runtime  Environments  (RTEs)  are  the 
largest  single  impediment  to  using  Ada  m  real-time  embedded  applications.  Other  areas  of 
concern  include:  management  understanding  of  Ada  technology  and  its  demand  on 
resources,  and  the  efficiency  of  the  generated  code. 

For  the  current  state  of  Ada  technology  there  are  two  classes  of  real-time  embedded 
applications  which  are  not  able  to  use  Ada  given  the  state  of  the  current  technology.  The 
first  class  are  the  implementations  with  8K  l^es  or  less  of  memory  capacity.  Although  the 
Ada  runtime  environment  sizes  are  becoming  smaller,  they  are  not  sinall  enough  yet.  Even 
a  customized  version  is  too  large  for  this  class  of  applications.  There  is  no  benefit  to  forcing 
Ada  into  this  memory  size.  It  will  require  contortions  that  are  likely  to  make  the  code  less 
reliable,  and  the  effon  of  rewriting  these  ^plications  is  unlikely  to  be  a  major  cost  given 
their  small  size.  The  second  class  of  real-time  embedded  applications  which  should  not  be 
required  to  use  Ada  are  the  micropragraimned  custom  hardtwe  systems.  It  is  unlikely  that 
Ada  compilers  will  be  produced  for  the  large  number  of  unique  processors  built  from 
bit-slice  components. 

A  common  difficulty  is  selecting  an  Ada  implementation,  especially  the  runtime  support 
routines,  that  will  meet  the  neetu  of  the  application.  The  ^t  source  of  information  should 
come  from  the  compiler  vendors.  The  application  requirements  should  be  explained  to  the 
compiler  vendor  and  the  compiler  vendor  should  explain  how  their  runtime  fits  (or  does  not 
fit)  the  requirements.  It  may  be  necessary  for  tne  contraaor  to  sign  a  non-disclosure 
agreement,  since  occasionally  the  details  of  the  commercially  available  runtimes  are 
proprietary.  Obviously,  the  application  engineers  need  to  be  included  in  the  compiler 
selection  process  to  evaluate  the  tradeoffs  involved. 

Although  compiler  vendors  are  becoming  more  knowledgeable  regarding  real-time  software 
development,  they  still  need  more  information  about  the  nature  of  embedded  applications 
and  the  relative  priorities  for  ad^essing  the  problems  associated  with  the  RTu.  On  the 
other  hand,  defense  contractors  understand  the  application  requirements  but  they  require 
education  on  Ada  runtimes  with  respect  to  the  Ada  language  features. 

Ada  can  be  used  successfully  on  real-time  embedded  systems,  even  with  traditional 
methods.  The  full  benefits  of  Ada  may  not  be  fully  realized  however,  if  new  methods  are 
not  adopted  to  facilitate  issues  such  as  maintainability  and  reusability. 

Ada  projects  can  run  into  serious  problems  at  several  different  points  in  the  life-cycle. 
Initially,  in  the  design  phase  there  may  be  serious  training  problems  and  a  need  to  provide 
better  guidelines  for  use  of  an  Ada  Program  Design  Language  (PDL).  The  most  likely 
"criticaT  area  occurs  in  the  test/debug  phase  where  timing  and  sizing  measurements  may 
differ  substantially  from  originai  premetions.  A  method  for  rapid  prototyping  should  be 
utilized  to  help  identify  these  problems  earlier  in  the  development  phase. 
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6.  Summary  Of  Interviews 

LabTek  prepared  a  list  of  questions  that  would  provide  much  of  the  infonnatioa  needed. 
These  questions  were  used  as  a  guide  for  the  ducussions  when  interviewing  each  project 
manager,  software  manager,  and  application  engineer.  Not  all  questions  could  be  answered 
by  everyone  and  some  clarification  of  the  questions  was  needed.  The  following  is  the 
imormation  received  from  the  projects.  The  contributions  of  all  the  individuals  who 
assisted  with  this  effort  is  acknowledged  and  appreciated.  The  information  that  they 
supplied  will  assist  in  making  positive  changes  to  the  way  Ada  is  used  in  U.S.  Army 
programs. 

The  following  is  a  list  of  the  most  prominent  issues  reported: 

*  Runtime  Library  Too  Large 

The  PM  or  contractor  reported  that  the  runtime  library  was  too  large  (size  in  bytes) 
for  the  memory  capacity  of  the  system.  In  most  cases,  this  was  a  problem  if  memory 
'  was  a  constraint. 

*  Required  Customized  Runtime  Library 

The  PM  or  contraaor  reported  that  it  was  necessary  to  modify  the  nmtime  library. 
Customization  was  performed  for  a  number  of  reasons,  the  main  one  being  the 
runtime  library  was  too  large  for  the  memory  capacity.  The  features  not  absolutely 
needed  were  stripped  out.  The  other  reason  that  it  was  modified  was  to  improve  the 
performance. 

*  Generated  Code  Not  Sufficiently  Optimized 

The  PM  or  contraaor  reported  problems  due  to  the  quality  of  the  generated  code. 
The  generated  code  was  not  as  efficient  as  code  that  could  be  produced  by  a 
programmer  coding  in  assembler. 

*  Memory  Was  a  System  Constraint 

Memory  capacity  was  a  constraint  and  therefore  required  careful  management  of  it. 

*  Lack  of  Chapter  13  Posed  a  Problem 

The  PM  or  contraaor  reported  problems  due  to  the  insufficient  implementation  of 
Chapter  D  of  the  Reference  Manual  for  the  Ada  Programming  Language.  It  is 
interesting  to  note  that  in  Figure  3.,Tercentage  Table  for  Reponed  Problems",  this 
problem  had  the  largest  discrepancy  between  what  the  contraaors  reported  and  what 
the  PMs  reported. 

*  Tasking  Algorithm  Unusable  For  Real>Time 

The  PM  or  contraaor  reported  that  the  tasking  features  were  too  time  consuming  to 
be  used  in  a  real-time  application. 

*  Compiler  Documentation  Was  Inadequate 
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The  PM  or  contractor  reported  that  the  compiler  documentation  was  inadequate  for 
the  problem  at  hand. 

Figure  3.,  "Percentage  Table  for  Reported  Problems",  provides  the  percentages  of  the 
interviews  that  reported  the  same  problem.  The  left  most  column  identifies  the 
problems.  The  second  column  contains  the  percentage  of  PMs  and  contracton 
combined  that  reported  the  same  problem.  The  numbers  in  this  column  are  based  on 
sixteen  (16)  different  interviews.  The  third  column  contains  the  percentage  of  PMs 
only  that  reported  a  specific  problem.  The  numbers  in  this  column  are  based  on 
interviewing  ei^t  (8)  PMs.  The  fourth  column  contains  the  percentage  of  the 
contraaots  only  that  reported  the  same  problem.  It  is  based  on  interviewing  eight  (8) 
contractors. 
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Figure  3.  Percentage  Table  for  Reported  Problems 
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7.  Glossary 

For  definitions  of  standard  software  engineering  terminology  the  reader  is  asked  to 
refer  to  the  ANSI/IEEE  Std  729-19^  "IEeE  Standara  Glossary  of  Software 
EnMeering  Terminology".  Terminology  not  defined  in  the  IEEE  standard  will  be 
demied  in  this  glossary. 

The  "Ada  community"  is  comprised  of  people  in  industry,  academia,  and  the 
government  using  Ada  technology  for  their  specific  requirements.  It  also  includes  the 
group  of  people  who  attend  the  SIGAda  Conferences,  and  the  readers  of  Ada 
LETTERS.  The  Ada  Runtime  Environment  Working  Group  (ARTEWG)  as  well  as 
the  Ada  compiler  vendors  are  also  part  of  the  "Ada  community”. 

"Ada  Technology”  consists  of  the  cunently  available  Ada  compilation 
systems,  tools,  and  associated  methodologies. 

An  "embedded  system"  is  a  computer  that  is  programmed  tt^rovide  specific 
functions  and  integrated  into  a  much  larger  system.  Typically,  the  embedded 
computer  is  used  to  control  or  monitor  the  operation  of  the  larger  system.  An 
exarnple  would  be  a  pilot's  advisory  system  onboard  an  aircrafL  Its  function  is  to 
provide  the  pilot  with  information  such  as  aircraft  roll,  pitch,  heading,  weight,  fuel 
reserves,  etc,  and  it  is  integrated  with  the  entire  flight  system. 

A  "real-time"  5^em  can  best  be  differentiated  by  its  quality  of 
responsiveness.  The  question  of  how  responsive  a  system  must  be  before  it  merits 
designation  as  real-time  is,  of  course,  a  relative  one.  For  this  report,  "real-time”  will 
mean  that  certain  processing  must  take  place  in  a  time  critical  range  to  insure  proper 
system  functionahty.  That  is,  the  system  will  not  operate  at  ail  if  this  ame  is 
exceeded,  as  opposed  to  operating  in  a  degraded  mode. 

It  follows  from  the  above  two  definitions  that  a  "real-time  embedded  system  ' 
is  a  computer,  programmed  to  perform  a  specific  function,  integrated  into  a  much 
larger  system  that  must  respond  to  external  events  in  an  expedient  manner  to  provide 
the  functionality  required.  Characteristics  of  real-time  embedded  system  software  are 
the  following: 

”  time  critical  calculations  must  be  performed  periodically  (in  a  frame  time, 
typically  in  the  millisecond  range) 

*  memory  is  usually  limited 

*  interrupts  signal  an  external  event  and  must  be  handled  in  an  expedient 
manner  (typically  in  the  microsecond  range) 

*  some  type  of  data  transmission  is  to  take  place  if  it's  a  distributed  system. 

Examples  of  computations  and  functions  performed  by  real-time  embedded  systems 
are: 


*  the  sampling  of  inertial  navigation  data 
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*  the  driving  of  servos 

*  performing  ballistic  calculations 

*  providing  data  for  a  feedback  loop 

*  transmitting/receiving  data  from  one  node  of  a  distributed  system  to  the  next 

*  performing  signal  processing 

*  performing  Kalman  filtering. 

"Runtime  Support  (often  called  runtime)"  is  the  set  of  procedures  or 
functions  required  to  support  the  code  generated  from  a  compilation  (Le.  entry  call 
in  a  task,  exception  raising  abort  processing,  string  catenation,et&). 

The  "Runtime  Support  Libra^  (RSL)  is  the  library  of  procedures  and 
'functions  from  whi(±  the  runtime  routines  are  selected.  The  runtime  consists  of  a 
subset  of  the  RSL. 

The  "Runtime  Environment"  (RTE)  includes  all  of  the  runtime  routines,  the 
conventions  between  the  runtime  routines  and  the  compiler,  and  the  underlying 
virtual  machine  of  the  target  computer.  Virtual  is  used  in  the  sense  that  it  may  be  a 
machine  with  layered  softie  (a  host  operating  system).  An  RTE  does  not  include 
the  application  ttself,  but  includes  everything  the  application  can  interact  with  (see 
Figure  2).  Each  layer  has  a  protocol  between  it  and  the  layer  underneath  it  for 
interfacing  In  the  event  that  there  isn't  an  operating  system  layer,  the  rtmtime 
includes  those  low-level  fimctions  found  in  an  operating  system. 

"Software  engineering^  is  the  discipline  and  skillful  use  of  suitable  software 
development  tools  and  methods  as  well  as  sound  understanding  of  certain  basic 
principles  relating  to  software  design  and  implementation. 

The  "Software  Engineering  commnniQr”  is  con^rised  of  people  in  academia, 
industry,  and  government  who  are  involved  in  the  fields  of  computer  science  and 
software  engmeerii^  It  also  includes  the  literature  such  as:  lEEc  Transactions  on 
Software  Engineering,  IEEE  Software,  ACM  Software  Engineering  Notes,  among 
other  publications. 
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1.  INTRODDCTION 


1.  1  Purpose 


It  is  now  the  policy  of  the  0.  S.  Department  of  Defense  (DoD) 
that  Ada  shall  be  the  singlet  coaunon,  high-order  programming 
language  for  all  computers  that  are  integral  to  weapon 
systems  [Ref.  1].  Ose  of  validated  Ada  compilers  is  required 
on  all  projects,  as  is  the  use  of  Ada-based  program  design 
language  (PDL). 


This  technical  report  investigates  some  of  the  generic  problems 
that  have  arisen  when  this  policy  has  been  followed  on  actual 
projects  and  relates  them  to  the  software  engineering 
principles  embodied  in  DoD  Standard  2167  [Ref.  2], 


I.  2  Terminology 


The  definitions  given  in  2167  apply  to  all  terms  used  in  this 
report,  with  additional  terms  defined  in  AMSI/IEEE  Std  729- 
1983  [Ref.  3]  and  in  Paragraph  3  of  this  report. 


1. 3  Organization 


The  report  is  organized  to  first  show  the  methods  used  to 
obtain  the  reported  problems  in  Paragraph  4.  The  problems 
themselves  are  then  analyzed  according  to  the  categories  of 
software  engineering  principles  which  they  affect,  with  the 
results  of  the  analyses  collected  in  dBASE  III  compatible 
files.  These  are  available  in  computer-readable  format  as 
well  as  being  presented  in  the  Appendix. 

The  main  findings  of  this  report  are  summarized  in  Paragraph  5, 
which  contains  a  list  of  the  problems,  the  relative  importance 
of  each  problem,  and  the  categorization  of  each  problem  in 
the  analysis  matrix  used  by  the  data  base.  Paragraph  5  also 
contains  the  Sonicraft  recommendations  for  the  use  of  the 
information  presented  herein. 
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3.  DEFINITIOHS 

Runtime  Support  or  Runtime  Support  Library  (RSL) :  The  set  of 
embedded  firmware  required  to  interface  the  applications  object 
code  generated  by  the  Ada  compiler  to  the  target  machine 
instruction  set. 

MEECN:  Minimum  Essential  Emergency  Communication  Network,  a 

stand-alone  network  that  is  intended  to  continue  operating 
reliably  after  the  primary  (higher  bandwidth)  communication 
network  has  failed  (such  as  after  a  natural  disaster  or  a 
nuclear  event). 

PAMELA:.  Process  Abstraction  Method  for  Embedded  Large 
Applications,  a  trademark  of  George  Cherry  for  his  Ada  design 
methodology. 

Real-Time  Function:  Any  system  function  (hardware,  software 
or  a  combination)  which  is  considered  to  have  faulted  if  it 
has  not  been  completed  within  a  specified  time  after  a  signal 
to  start.  . 

Real-Time  Ada:  A  computer  program  written  in  the  Ada  language 
which  implements  one  or  more  real-time  functions,  usually 
triggered  by  interrupts. 

Efficiency:  Efficiency  deals  with  u t i 1 iz at i on  of 

resources.  The  extent  to  which  a  component  fulfills  its 
purpose  using  a  minimum  of  computing  resources.  Of  course, 
many  of  the  ways  of  coding  efficiently  are  not  necessarily 
efficient  in  the  sense  of  being  cost  effective,  since 
transportability,  maintainability,  etc. ,  may  be  degraded  as  a 
result. 

Integrity:  ' Integrity  deals  with  software  failures  due  to 
unauthorized  access,  and  is  the  extent  to  which  access  to  a 
component  or  associated  data  by  unauthorized  persons  can  be 
controlled. 

Reliability  -  Those  characteristics  of  software  which  provide 
for  definition  and  implementation  of  functions  in  the  most 
non-complex  and  understandable  manner.  By  reducing  complexity 
the  chances  of  the  progreun  providing  the  functions  as  intended 
are  increased,  thereby  improving  reliability. 

Survivability  -  Survivability  deals  with  the  continued 
performance  of  software  (  e. g. ,  in  a  degraded  mode)  even  when  a 
portion  of  the  system  has  failed. 

□sability  -  Oser  effort  required  to  learn,  operate,  prepare 
input  for,  and  interpret  output  of  a  component. 

Correctness  -  The  extent  to  which  software  design  and 
implementation  conform  to  specifications  and  standards. 
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Criteria  of  correctness  deal  exclusively  with  design  and 
documentation  formats,  such  as  agreements  between  a  component's 
total  response  and  the  stated  response  in  the  functional 
specification  (functional  correctness),  and/or  between  the 
component  as  coded  and  the  programming  specification 
(algorithmic  correctness). 

Maintainability  -  The  ease  of  effort  in  locating  and  fixing 
software  failures.  The  extent  to  which  a  component  facilitates 
updating,  to  satisfy  new  requirements  or  to  correct 
deficiencies.  This  implies  that  the  component  is 
understandable,  testable,  and  modifiable. 

Verifiability  -  Software  design  characteristics  affecting  the 
effort  required  to  verify  softwetre  correctness. 

Portability  -  A  property  of  a  program  representing  ease  of 
movement  among  distinct  solution  environments. 

Reusability  -  The  extent  to  which  a  component  can  be  adapted 
for  use  in  another  environment  (e. g. ,  different  host  or  target 
hardware,  operating  system,  APSE)  or  another  application. 

Expandability  (Extendibility,  Flexibility)  -  A  measure  of  the 
effort  in  increasing  software  capabilities  or  performance  or  to 
accommodate  changes  in  requirements,  or  the  extent  to  which  a 
component  allows  new  capabilities  to  be  easily  tailored  to  user 
needs. 

Training  -Those  characteristics  of  software  which  provide 
transition  from  current  operation  and  provide  initial 
familiarization.  A  measure  of  the  extent  to  which  training  and 
other  user  help  is  available  from  the  vendor  of  a  con^onent 
or  from  the  component  itself,  including  on-line, 
documentation,  listings,  and  printouts,  which  serve  the 
purpose  of  providing  operating  instructions  for  using  the 
component  to  obtain  desired  results. 

Configuration  Mgmt  -  A  measure  of  the  discipline  related 
to  controlling  the  contents  of  a  component,  including 
monitoring  the  status,  preserving  the  integrity  of  released 
and  developed  versions,  and  controlling  the  effects  of  changes 
throughout  the  component. 

Costs  -  The  cost  of  a  complete  component  or  the  costs  of 
features  of  a  component.  Other  cost  considerations  are 
installation,  user  assistance,  and  maintenance  support. 

Allocator  -  An  allocator  creates  a  new  object  of  an  access 
type,  and  returns  an  access  va)'ie  designating  the  created 
object. 

Elaboration  -  Elaboration  is  the  process  by  which  a 
declaration  achieves  its  effect.  For  example  it  can  associate 
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a  name  with  a  program  entity  or  initialize  a  newly  declared 
variable. 

Exception  -  An  exception  is  an  event  that  causes  suspension  of 
normal  program  execution.  Bringing  an  exception  to 
attention  is  called  raising  the  exception.  An  exception 
handler  is  a  piece  of  program  text  specifying  a 
response  to  the  exception.  Execution  of  such  program 
text  is  called  handling  the  exception. 

Rendezvous  -  A  rendezvous  is  the  interaction  that  occurs 
between  two  parallel  tasks  when  one  task  has  called  an  entry  of 
the  other  task,  and  a  corresponding  accept  statement  is 
being  executed  by  the  other  task  on  behalf  of  the  calling  task. 

Task  -  A  task  is  a  program  unit  that  may  operate  in  parallel 
with  other  program  units.  A  task  specification  establishes 
the  name  of  the  task  and  the  names  and  parameters  of  its 
entries:  a  task  body  defines  its  execution.  A  task  type 
is  a  specification  that  permits  the  subsequent  declaration  of 
any  number  of  similar  tasks. 

Visibility  -  At  a  given  point  in  a  program  text,  the 
declaration  of  an  entity  with  a  certain  identifier  is  said 
to  be  visible  if  the  entity  is  an  acceptable  meaning  for  an 
occurrence  at  that  point  of  the  identifier. 


REAL-TIME  ADA  PROBLEM  STODY 


10/  9/  87 


4.  APPROACH 

Sonicraft  used  a  five  step  approach  to  meet  the  objectives  of 
this  program; 

1)  Identify  the  sources  which  could  identify  problems 
in  developing  Ada  software  for  computer  which  are 
integral  to  weapon  systems. 

2)  Identify-  the  relevant  problems. 

3)  Isolate  the  problems  that  are  generic. 

4)  Classify  the  problems  based  on  which  aspects  of 
Software  Engineering  are  affected  by  each  problem. 

5)  Analyze  the  effects  of  each  problem  for  each  of 
these  categories. 

4.  1  Sources 

The  main  source  of  problems  was  our  own  experience  in  develop¬ 
ing  the  MEECN  system,  which  is  the  first  weapon  system 
developed  using  the  Intel  8086  microprocessor  and  the  full  Ada 
programming  language  (including  tasking  and  other  non- 
Pascal  features).  There  were  literally  hundreds  of  problems 
which  were  encountered  in  this  development,  and  most  were  at 
least  thought  to  be  Ada-related  at  the  time  of  their 
occurrence. 

Other  sources  which  were  planned  included  contacts  from  the  Ada 
Joint  Program  Office  (AJPO)  Evaluation  and  Validation  (E&V) 
Team;  other  personal  contacts  from  the  government,  industry  and 
academia;  information  from  SIGAda,  the  National  Ada  Symposium, 
and  other  Ada  conferences;  and  information  from  Ada-related 
publications. 


Due  to  replanning  to  stretch  out  the  period  of  performance  of 
our  task,  some  of  the  planned  contacts  were  postponed  to  the 
next  phase  of  this  contract.  These  contacts  should  be  made 
to  broaden  the  data  base  of  this  study  and  to  avoid  the 
impression  that  it  is  based  solely  on  the  experiences  of  one 
org^ulization. 

4.  2  Relevant  Problems 

Sonicraft  capitalized  on  the  MEECN  project  experience  by 
concentrating  on  the  Ada  problems  that  arose  from  Intel 
targets.  Since  the  MEECN  project  is  still  in  formal  test, 
and  more  hardware  integration  problems  will  probably 
still  be  found,  Sonicraft  also  concentrated  on  the  early  phases 
of  Che  Software  Life  Cycle. 
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Problems  were  accepted  for  tills  study  only  when  the  root 
cause  had  been  determined  unambiguously.  In  practice  this 
meant  that  the  problem  had  been  solved  and  had  not  returned 
in  subsequent  software  tests.  This  caveat  was  necessary 
because  Sonicraft  had  found  problems  that  appeared  to  be 
Runtime  Support  Library  (RSL)  problems  of  the  Ada  compiler,  but 
were  later  found  to  be  due  to  other  causes.  For  example,  the 
Intel  Microprocessor  Development  System  once  had  a  probe 
which  gave  erroneous  readings  due  to  a  calibration  problem. 
Until  this  was  discovered  during  a  system  verification  by 
Intel,  Sonicraft  was  searching  for  a  nonexistent  RSL  problem. 

4.  3  General  Problem 

To  be  considered  generic,  a  problem  must  have  been  reported  by 
more  than  one  source.  In  addition,  problems  that  stemmed  from 
a  common  cause  were  grouped  together  as  symptoms  of  the 
root  probleou  As  an  example,  Sonicraft  experienced  problems  in 
using  several  Ada  Language  System  (ALS)  tools,  but  these  were 
grouped  together  as  part  of  a  single  problem  (#16)  rather  than 
treating'  each  separately.  By  doing  this  the  original  set  of 
hundreds  of  problems  was  distilled  to  a  more  manageable  (and 
understandable)  set  of. 

By  treating  only  generic  problems  Sonicraft  expects  that 
users  of  this  report  will  be  more  likely  to  find  the  problems 
they  can  expect  to  encounter. 


4.  4  Classification 

The  generic  problem  impacts  were  classified  into  six  major 
categories: 

1)  Attributes  of  the  delivered  application 

2)  Methodology  used  to  develop  the  application 

3)  Implementation  of  the  application 

4)  Tools  used  to  develop  the  application 

5)  Phase  of  the  Software  Development  Cycle  where 
the  problem  occurs 

6)  Management  impacts  on  the  application 

These  categories  were  then  subclassified  into  51 
subcategories,  most  of  which  were  found  to  be  applicable  to  at 
least  one  Ada  problem.  This  part  of  the  process  is  very 
aunenable  to  update,  as  new  or  better  categories  can  be  added 
reasonably  quickly  with  the  more  manageable  set  of  37  problems 
to  work  with. 
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4. 5  Analysis 

The  analysis  of  each  generic  problem  consists  of  first  a 
problem  definition,  then  detailed  write-ups  showing  its  impact 
on  each  applicable  Software  Engineering  subcategory*  The' 
detailed  analysis  establishes  exactly  MEAT  the  problem  is, 
references  WHO  (or  WHERE]  it  came  from,  and  explains  WHY  it  is 
a  problem.  Its  purpose  is  to  provide  enough  background 
material  so  that  the  subcategocy  analyses  will  be  more 
meaningful.  This  section  normally  concludes  with  a  brief 
summary  of  Sonicraft's  conclusions  about  the  overall  effect 
of  the  problem. 

The  detailed  write-ups  in  each  subcategory  provide  information 
needed  for  a  full  understanding  of  the  analysis,  such  as  WHEN 
the  problem  occurs  in  the  Software  Development  Life^cle,  and 
how  its  symptoms  (often  unrecognized  as  rooted  in  this  generic 
problem]  may  extend  to  later  phases  of  the  Lifecycle. 

Where  problems  are  related  to  other  generic  problems,  the 
relationship  is  highlighted  in  the  portions  of  the  analysis 
where  it  is  most  needed  to  understand  the  problem  under 
analysis. 

Assumptions  were  not  intentionally  made  in  the  analysis  of 
any  of  the  problems,  but  in  several  instances  the  opinion  of  a 
problem  source  is  reported.  These  instances  include  specific 
references  to  the  source  so  that  the  reader  can  investigate 
these  opinions  in  more  depth  if  desired. 

In  many  cases  a  rationale,  such  as  a  developer  of  the 
Ada  software  for  computers  integral  to  weapon  systems  might 
use,  is  presented  to  help  in  understanding  why  something 
might  be  considered  a  problem.  The  use  of  a  rationale 
is  not  a  scientifically  valid  method  to  support  a  conclusion, 
of  course,  but  was  included  where  it  helped  to  visualize 
the  kinds  of  things  that  experienced  developers  worry  about. 

Notably  missing  from  this  analysis  is  the  recommendation  of 
what  to  do  about  the  problems.  This  omission  was  deliberate 
because  it  requires  additional  data  collection  and  analysis  to 
arrive  at  sound  conclusions.  Even  then  these  conclusions  must 
be  tested  to  achieve  enough  credibility  to  convince  people 
to  take  the  trouble  to  implement  them.  These  efforts  are 
beyond  the  scope  of  the  present  Sonicraft  task. 
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3.  SDMMARY  AND  RECOMMENDATIONS 


5. 1  Format  of  Problem  Analysis 

Figure  5-1  presents  a  list  of  the  generic  problems  that  were 
found  to  result  from  the  use  of  Ada  in  computers  that  are 
integral  to  weapons  systems.  The  importance  shown  for  each 
problem  is  determined  as-  follows: 

VI  a  Very  Important  problem  in  terms  of  its  impact  on 
developers  crying  to  use  Ada.  Requires  awareness  of  the 
developers  and  needs  attention  to  develop  good  solutions 
as  soon  as  possible. 

I  *  Important  problem#  but  not  as  potentially  damaging  to  a 
development  effort  as  the  VI  problems. 

LI  a  Least  Important  problem  coit^ared  to  the  others,  but 
still  worthy  of  attention  to  develop  a  good  solution. 

Figure  5-1  also  presents  a  matrix  of  these  problems  versus 
the  software  engineering  categories  they  affect.  The  Appendix 
presents  a  definition  of  each  problem,  a  definition  of  each 
category,  and  a  problem  Impact  analysis  on  each  category 
wherever  an  ”X*  appears  in  the  figure. 

5.  2  Summary  of  Findings 

The  generic  problems  seem  to  convey  two  messages  over  and  .over: 

1)  It  is  a  lot  more  expensive  to  do  programming  in  Ada. 

2)  Worse  yet,  for  some  applications  it  is  not  yet  techni¬ 
cally  feasible. 

Our  conclusion  after  analyzing  these  problems  is  that 
situation  is  not  necessarily  that  bleak  for  a  developer 
starting  out  in  Ada  today.  Some  of  the  damage  these  problems 
can  cause  can  be  averted  simply  by  knowing  about  them  and 
then  exercising  reasonable  vigilance  (i.  e..  Problem  #17).  To 
the  extent  that  this  is  possible,  this  report  is  intended  to 
be  of  immediate  benefit. 

Another  point  to  consider  is  that  most  of  the  Very  Important 
problems  are  related  to  Ada  compiler  technology  in  some 
way.  The  focus  of  this  report  has  been  on  cross-compilers 
targeted  to  the  Intel  8086  microprocessor,  which,  while  being 
the  most  widely-used  microprocessor  in  the  world,  is  not 
particularly  well  suited  for  Ada  tasking.  Subsequent  products 
from  Intel  are  much  better  in  this  regard.  Also,  the  8086- 
cargeted  compilers  have  markedly  improved  about  every  six 
months  since  the  first  one  was  validated  less  than  two  years 
ago.  While  it  is  dangerous  to  extrapolate  this  trend  to  the 
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future,  it  is  nevertheless  encouraging. 


Finally,  the  tone  of  this  report  has  been  set  by 

intentionally  concentrating  on  the  problems  in  the  use  of 
Ada.  A  similar  report  concentrating  on  thirty-seven 
advantages  in  the  use  of  Ada  for  computers  integral  to 

weapons  system  could  have  been  written  instead,  and  it  would 

have  given  the  opposite  impression.  In  fact,  we  see  the 
introduction  of  Ada  as  a  tremendous  boost  to  productivity, 
but  only  after  problems  similar  to  those  analyzed  here  have 

been  addressed. 

5. 3  Recommendations 

Sonicraft  recommends  that  the  poroblem  data  base  be  enriched  in 
three  ways: 

1)  Periodically  reassess  the  problems  since  Ada 
technology,  especially  for  compilers,  is  very 

'  dynamic. 

2)  Determine  the  effects  of  using  current  development 

methodologies  on  the  frequency  of  problem  occurrence. 

3)  Determine  a  problem  avoidance  matrix,  constructured 
similarly  to  figure  5-1,  showing  what  developers  do 
to  avoid  or  minimize  the  occurrence  of  generic 
problems. 

These  extensions  and  updates  will  magnify  the  benefits  of  this 
report  and  help  speed  the  acceptance  of  Ada  as  a  viable 
language  for  embedded  processors. 


APPENDIX  10 
REAL  TIME  ADA  PRCSLEMS 
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10.  1  LACK  OF  KNOWLEDGE  CONCERNING  TEE  ADA  RON-TIME 
ENVIRONMENT 

10.  1.  1  Definition 

The  language  provides  a  very  complex,  powerful,  and 
sophisticated  run-time  environment  to  support  such  Ada 
features  as  memory  management,  process  control,  and  others. 
The  primary  element  in  the  Ada-supplied  run-time  environment  is 
the  Run-Time  Support  Library  (RSL).  The  RSL  performs  a 
number  of  activities  which  include: 

*  Memory  Management 

Dynamic  memory  allocation/deallocation 
Garbage  collection 

*  Process  Scheduling 

Task  activation/deactivation 
Task  scheduling 
Task  rendezvous 

*  Resource  Control 

Resource  scheduling 
Resource  monitoring 

*  Error  Processing  (exception  handling) 

The  RSL  resides  in  the  target  environment  during  system 
operation  and  operates  in  conjunction  with  the  applications 
software. 

The  performance  of  the  RSL  affects  the  performance  of  the 
applications  programs  (tasking,  memory  management,  interrupts, 
etc.).  The  RSL  is  also  part  of  the  system  debug/testing 
process  since  it  resides  in  the  target  environment.  The  RSL 
may  require  customization  as  part  of  the  system  optimization 
process.  The  RSL  may  need  to  be  benchmarked  to  obtain  an 
accurate  estimate  of  system  performance. 

The  information  concerning  the  RSL  characteristics  is  vital  to 
the  applications  developers,  since  they  nust  address  the  impact 
of  the  RSL  during  system  design  and  implementation.  If  this 
information  is  not  made  available  to  the  applications 
programmers,  there  is  little  hope  that  the  system  being 
developed  will  perform  as  expected.  To  date,  the  Ada 

compiler  vendors  have  provided  little  information  to  the  Ada 
applications  developers  concerning  the  detailed  sizing,  timing, 
performance,  and  functional  characteristics  of  the  RSL. 


10.  1.  2  Maintenance 
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The  implefflentatlon  of  cheoiges  to  an  Ada  program  is  dependent  on 
the  capabilities  of  the  REL  and  the  interfaces  between  the  RSL 
and  the  programs  being  maintained.  Lack  of  knowledge 
concerning  the  RSL  could  result  in  the  implementation  of 
program  changes  without  a  full  understanding  of  their  impact  on 
system  performance. 

10.  1.  3  Correctness 

The  Ada  run-time  environment  includes  the  resident  REL  programs 
which  interact  with  the  applications  program(s).  Lack  of 
knowledge  concerning  the  RSL  could  lead  to  misunderstandings 
concerning  the  functions  of  the  RSL  and  the  applications 
programs.  These  programs  could  lead  to  the  development  of 
applications  programs  that  do  not  perform  as  expected. 

10.  1.  4  Verifiability 

During  the  testing  of  Ada  programs,  errors  that  are  found  must 
be  isolated  to  program  components  so  that  they  can  be 
corrected.  Lack  of  knowledge  concerning  the  RSL  causes  added 
difficulty  in  isolating  and  correcting  these  errors  because  it 
is  difficult  to  determine  whether  the  error  is  due  to  an 
incorrect  applications  program,  a  problem  in  the  RSL,  or  a 
misunderstanding  concerning  the  operation  of  the  REL  or  its 
interfaces  to  the  applications  programs. 

10.  1.  5  Risk 

The  development  problems  that  arise  from  a  lack  of  knowledge  of 
the  RSL  can  greatly  increase  the  risk  associated  with  the 
development  of  an  Ada  applications  program.  Technical  risk  can 
result  because  applications  programs  might  be  developed  that  do 
not  provide  expected  performance  or  capabilities  due  to  an 
incomplete  understanding  of  the  efficiency  and  functional 
capabilities  f  the  RSL.  Extensive  rework  and  redesign  may  be 
required  to  rework  these  deficiencies,  because  the  changes  that 
are  made  to  correct  these  problems  may  impact  other  areas  of 
the  sytem.  Cost  and  schedule  risk  are  also  factors  and  will  be 
addressed  as  project  management  issues. 

10.  1.  6  Software  Requirements  Analysis 

Lack  of  knowledge  of  the  RSL  capabilities  could  prevent  Ada 
software  developers  from  performing  an  accurate  software 
requirements  analysis  with  regard  to  issues  such  as  sizing, 
timing,  performance,  and  functionality.  Since  the  RSL  operates 
in  conjunction  with  the  applications  software,  it  is  critical 
for  Ada  developers  to  know  the  characteristics  of  the  RSL  when 
attempting  to  determine  the  feasibility  of  meeting  proposed 
system  requirements. 

10.  1.  7  Preliminary  Design 
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Lacic  of  knowledge  concerning  RSL  functionality,  performance, 
and  interfaces  could  prevent  Ada  software  developers  from 
specifying  correct  and  efficient  interfaces  between  the  RSL  and 
the  applications  software.  The  performance  of  the  RSL  must  be 
addressed  while  performing  preliminary  system  sizing  and  timing 
analysis.  Also,  the  operations  that  are  performed  by  the  RSL 
(task  scheduling,  memory  management,  etc. )  must  be  considered 
when  attempting  to  determine  the  various  system  states. 

10.  1.  8  Detail  Design 

Lack  of  knowledge  concerning  the  implementation  details  of  the 
RSL  could  cause  problems  during  the  Detailed  Design  Phase.  The 
run-time  performance  of  the  RSL  must  be  addressed  when 
performing  the  detailed  system  sizing  and  timing  analyses. 
Accurate  information  concerning  the  interfaces  between  the  RSL 
and  the  applications  program  is  necessary  to  develop  the 
detailed  software  interface  definitions. 

10.  1.  9  CSC  Test 

During  CSC  integration  and  testing,  lack  of  knowledge 
concerning  the  functional,  performance,  and  interface 
characteristics  of  the  RSL  makes  it  very  difficult  for  the  Ada 
developers  to  isolate  software  errors.  Also,  any  problems  that 
originate  in  the  RSL  itself  (due  to  the  immaturity  of  the  run¬ 
time  programs)  are  almost  impossible  to  debug  unless  someone 
with  an  extensive  knowledge  of  the  RSL  code  .(most  likely 
supplied  by  the  compiler  developer)  is  available  to  the 
development  team. 

10.  1.  10  CSC  Test 

The  problems  that  occur  during  this  phase,  due  to  lack  of 
knowledge  of  the  RSL,  are  similar  to  those  described  in  the  CSC 
testing  phase.  They  all  result  from  rework  from  earlier  phases 
of  tasks  done  in  error  due  to  RSL  misunderstanding. 


10.  1.  11  System  Test 

The  problems  that  occur  during  the  system  testing  phase  due  to 
lack  of  knowledge  of  the  RSL  are  similar  to  those  that  occur  in 
the  CSC  and  CSCZ  testing  phases.  They  are  all  rework  of  tasks 
in  earlier  phases,  but  the  rework  is  much  more  expensive  in 
this  phase  because  of  the  formal  testing  that  must  be  repeated. 

10.  1. 12  Personnel  Rmsources 

Lack  of  knowledge  of  the  RSL  can  result  in  incorrect  design, 
which  then  requires  sometimes  extensive  rework  by  senior  staff 
members.  This  effort,  along  with  the  effort  necessary  to  learn 
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about  the  characteristics  of  the  RSL,  requires  the  use  of 
additional  personnel  resources. 

10.  1. 13  Cost 

The  development  problems  that  arise  from  a  lack  of  knowledge  of 
the  RSL  can  adversely  impact  system  development  costs.  This 
lack  of  knowledge  can  result  in  failure  to  design/ implement 
correct  interfaces  between  the  applications  programs  and  the 
RSL.  It  can  also  result  in  applications  programs  that  do  not 
provide  expected  performance  or  capabilities  due  to  an 
incomplete  understanding  of  the  efficiency  and  functional 
capabilities  of  the  RSL.  The  rework  and,  in  some  cases  these 
problems  can  cause  a  significant  increase  in  project 
development  cost. 

10.  1. 14  Schedule 

The  problems  that  can  arise  from  having  a  lack  of  knowledge 
concerning  the  RSL  characteristics  could  adversely  impact  the 
system  development  schedule. 
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10.  2  IMPACT  OF  ADA  COMPILER  IMPLEHBMTATION  DIFFERENCES 

The  differences  in  Ada  compiler  implementation  can  impact  the 
performance  of  an  Ada  application*.  The  ACVt,  tests  that  are 
used  by  the  AJPO  to  validate  candidate  Ada  compilers  primarily 
verify  the  functional  and  syntactical  aspects  of  the  compilers, 
they  do  not  address  performance  and  implementation  issues. 
Between  this  and  the  optional  implementation  issues  discussed 
in  Chapter  13  of  the  Ada  Language  Reference  Manual,  a  compiler 
vendor  has  some  flexibility  in  determining  a  compiler 
implementation  approach.  The  areas  in  which  the  impacts  of 
compiler  implementation  differences  are  most  likely  to  be 
observed  are: 

*  The  efficiency  of  the  generated  Ada  object  code 

*  The  size  of  the  RSL 

*  The  run-time  overhead  associated  with  the  RBL 

*  Implementation  of  language  features  (tasking, 
generics,  etc.  ) 

*  Compilation  speed  (lines  of  code  per  minute) 

Differences  in  compiler  implementation  can  have  an  effect  on 
system  performance.  They  can  cause  a  reduction  in  system 
efficiency,  thus  requiring  additional  system  resources 
(hardware  amd  software).  Impacts  can  also  be  felt  in  the  areas 
of  system  maintainability  (for  both  the  ‘Compiler  and  the 
applications  software)  and  in  modifications  that  must  be  made 
to  other  Ada  support  tools  (such  as  the  debugger]  to  reflect 
the  compiler  implementation  differences. 

10.  2.  1  Efficiency 

The  kCJC  tests  that  are  performed  to  validate  an  Ada  compiler 
are  primarily  concerned  with  functional  amd  syntactical  issues; 
they  do  not  address  implementation  and  efficiency  issues.  Thus 
a  different  compiler  implementation  that  provided  reduced 
efficiency  would  still  be  validated  if  it  passed  the  ACVC 

wGS  tlS* 

The  performance  of  an  Ada  compiler  is  affected  by  a  number  of 
issues  such  as  the  algorithms  employed  by  the  compiler  to 
perform  its  processing,  the  effectiveness  with  which  the 
compiler-generated  code  utilizes  the  system  architecture,  and 
the  performance  (execution  speed  and  memory  usage)  of  the 
compiler-generated  code. 

If  a  different  implementation  of  an  Ada  compiler  did  not 
perform  as  well  in  some  of  these  system-specific  and 
application-specific  areas,  the  result  could  be  a  reduction  in 
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the  overall  efficiency  of  the  system. 

10.  2.  2  Maintenance 

A  different  implementation  of  a  compiler  could -provide  reduced 
maintainability  for  the  compiler  itself,  if  the  implementation 
resulted  in  ah  increase  in  compiler  complexity.  The 
i^.aintainability  of  the  applications  programs  could  also  be 
adversely  affected  if  the  different  con^iler  implementation 
caused  an  increase  in  the  complexity  of  the*  compiler-generated 
object  code. 

10.  2.  3  Benchsuurk 

To  determine  the  anticipated  impact,  if  any,  of  a  different 
compiler  implementation  on  system  performance,  the  compiler 
should  be  benchmarked  to  assess  its  performance.  Along  with  an 
evaluation  of  overall  compiler  performance,  this  benchmarking 
should  address  those  areas  of  the  compiler  in  which  the 
different  implementation  could  adversely  impact  system 
performance. 

10-.  2.  4  Vendor  Interface 

The  differences  in  Ada  compiler  implementations  could  adversely 
impact  performance  of  the  compiler  and  the  compiler-generated 
code.  To  obtain  detailed  and  accurate  information  describing 
the  compiler  implementation  and  its  impact  on  system 
performance,  it  is  important  to  establish  a  relationship  with 
the  compiler  vendor.  The  compiler  vendor  can  provide  this 
information  to  the  applications  developers  and  can  help  them 
relace  these  results  to  the  system  development. 

10.  2.  5  Prototype 

To  determine  the  impact  of  the  different  Ada  compiler 
implementations  on  system  performance,  a  prototype  of  the  the 
system  should  be  developed.  This  allows  the  applications 
developers  to  obtain  an  actual  evaluation  of  the  impact  of  the 
different  compiler  implementations  in  their  application 
environment. 

10.  2.  6  Debugger 

Differences  in  the  implementation  of  the  Ada  compiler  can 
impact  the  design  of  the  system  debugger.  For  example, 
differences  in  the  target  machine  memory  layout  constructed  by 
the  compiler  must  be  incorporated  into  the  debugger  so  that  it 
reflects  the  differences. 
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10.  3  IMPACT  OF  INTERRUPT  HANDLING'  07EREEAD  ON  SYSTEM 
PERFORMANCE 

With  the  embedded  system  being  the  primary  target  for  the  use 
of  the  Ada  language,  the  efficient  handling  of  interrupts 
becomes  a  major  issue.  Interrupts  can  be  defined  as  hardware  or 
software  signals  that  stop  the  current  processes  of  the  system 
under  specified  conditions  and  in  such  a  way  that  the  processes 
can  be  resumed.  In  the  embedded  system  environment,  interrupts 
are  critical  to  the  ability  of  the  system  to  respond  to  real¬ 
time  events  and  perform  its  required  functions.  Interrupts,  in 
general,  signal  the  occurrence  of  some  predefined  event  to  the 
embedded  system.  The  embedded  system  must  then  perform  the 
correct  functions  in  some  determined  amount  of  time. 
Therefore,  any  overhead  time,  time  spent  on  processes  that  are 
over  emd  aibove  the  required  processes,  will  degrade  the  ability 
of  the  embedded  system  to  meet  its  functional  requirements.  To 
better  illustrate  the  problem,  please  note  the  following: 


1< - - B - >|< - C - >1 

A 


A  :  Represents  the  occurrence  of  a  interrupt. 

B  :  Represents  the  overhead  time  required  to  stop  the 
current  process  and  switch  to  the  interrupt 
handler  process. 

C  :  Represents  the  time  spent  performing  the  required 
processes  in  response  to  the  interrupt. 


The  problem  that  exists  with  Ada  today  is  the  overhead  time  ”B* 
that  is  required  in  a  Ada  program  to  stop  and  switch  to  the 
interrupt  handling  process  is  too  large  and  in  many  cases 
unacceptable  for  embedded  system  applications.  Currently,  Ada 
programs  have  overhead  times  in  the  hundreds  of  microseconds  to 
milliseconds.  The  non-Ada  embedded  system  application  overhead 
times  have  been  in  tens  of  microseconds  or  less. 

10.  3.  1  Efficiency 

The  efficiency  of  the  application  program  will  be  directly 
affected  by  the  overhead  of  interrupt  handling.  n>us  the  system 
will  inefficiently  process  the  incoming  interrupts.  The  more 
interrupts  the  system  has  to  process  per  unit  time  will 
determine  how  inefficient  the  application  program  and  the 
system  will  be. 
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10.  3.  2  Reliability 

With  the  amount  of  overhead  associated  with  the  processing  of 
embedded  system  interrupts,  one  must  be  very  careful  in  the 
design  of  an  Ada  system.  Because  the  period  of  time  it  takes  to 
begin  executing  the  interrupt  handler  can  vary,  it  is  possible 
for  the  system  to  occasionally  miss  an  interrupt.  This  usually 
compromises  the  functioning  of  the  system  and.  may  even  shut  it 
down. 


10.  3.  3  Portability 

Portability  of  Ada  programs  will  prove  to  be  more  difficult, 
since  interrupt  processing  in  an  implementation  depends  on 
features  of  the  RSL.  The  timing  involved  in  the  execution  of 
interrupts  using  one  compiler  cannot  be  guaranteed  to  work  on 
another  compiler. 

10.  3.  4  Benchmark 

Benchmarking  is  often  required  when  a  new  set  of  tools  is  being 
evaluated  for  use  on  a  given  project.  Because  of  the  critical 
nature  of  interrupts  to  the  performance  of  real-time  embedded 
systems,  there  is  a  strong  need  to  develop  some  detailed 
benchmark  tests  to  evaluate  the  characteristics  of  the  tools 
with  respect  to  interrupts.  By  developing  a  set  benchmark 
tests  the  project  will  be  able  to  evaluate  the  various  tools 
available  and  select  the  set  of  tools  best  suited  to  meet  the 
requirements  of  the  given  project.  This  can  produce  major  cost 
savings  later  in  'the  life  cycle  because  of  proper  tool 
selection. 

10.  3.  5  Simulation 

After  the  interrupt  characteristics  of  a  particular  set  of 
tools  have  been  tested  and  the  results  show  that  there  may  be 
some  risk  of  meeting  the  requirements,  than  a  series  of  risk 
reduction  simulations  are  required.  The  purpose  of  the 
simulation  effort  will  be  one  to  determine  the  impact  on  the 
design  of  the  system  and  two  what  course  of  action  must  be 
taken  for  risk  reduction.  To  perform  these  steps  the  simulation 
effort  will  simulate  a  subset  of  the  required  functions  of  the 
embedded  systems.  The  functions  to  be  simulated  are  those 
functions  that  show  a  high  degree  of  risk.  For  this  particular 
problem  of  interrupt  overhead  impact,  the  designer's  aim  is  to 
reasonably  prove  or  disprove  that  he  can  meet  the  requirements 
of  the  project.  Simulations  are  one  of  the  best  ways  to 
determine  early  in  the  project  life  cycle  the  feasibility  of  a 
design  approach. 
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10.  3.  6  Optiaization 

Once  simulations  have  been  developed  and  the  designer  can 
experiment  with  the  problem  of  interrupt  overhead  impacts,  he 
can  determine  if  there  is  any  need  to  optimize  either  the  tools 
or  his  design  approach.  The  impact  of  performing  optimization 
can  be  delays  in  project  schedules,  cost  over-runs,  and  loss  of 
readability  and  maintainability.  Thus,  optimiz a-tion  effort 
would  only  be  conducted  if  it  is  determined  that  it  is  required 
to  meet  the  requirement  of  the  project. 

IG.  3.  7  System  Sizing 

In  the  embedded  system  environment  sizing  is  a  critical  factor 
and  any  overhead  impacts  will  directly  effect  the  sizing  of  the 
system. 

Such  is  the  case  for  the  overhead  associated  with  the  use  of 
Ada  interrupts.  Of  course,  benchmark  testing  and  simulations 
should  be  conducted  to  determine  the  full  impact  of  the 
overhead 'on  the  system  sizing  requirements.  If  it  is  determined 
that  there  is  to  much  risk  of  not  meeting  the  requirements, 
then  corrective  action,  such  as  optimizing  can  be  taken. 

10. 3.  8  System  Timing 

Another  critical  factor  in  the  development  of  the  embedded 
system  has  to  do  with  timing  or  the  ability  of  the  system  to 
respond  to  events.  Because  embedded  systems  rely  heavily  upon 
interrupts  to  signal  the  occurrences  of  external  events,  any 
overhead  associated  with  the  processing  of  the  interrupts  will 
directly  affect  the  system  timing. 

The  problem  is  compounded  if  the  system  requires  a  number  of 
interrupts  to  be  processed  at  a  high  frequency  rate.  Again, 
benchmark  testing  and  simulations  must  be  conducted  early  in 
the  project  life  cycle  to  determine  the  severity  of  the 
interrupt  overhead.  If  the  overhead  is  too  high,  then  often- 
costly  optimization  approaches  must  be  taken. 

10.  3.  9  Prototype 

nany  times  the  impact  to  system  timing  cannot  be  determined 
under  simulated  (mainly  software-software  testing)  conditions. 
Thus,  a  rapid  prototype  of  the  real  embedded  system  is 
required.  Because  the  prototype  is  similar  to  the  real  system, 
the  design  engineer  can  conduct  overhead  and  its  effects  on  the 
timing  of  the  system,  the  design  engineer  can  measure  and  test 
to  verify  if  the  system  can  respond  to  events  in  a  timely 
fashion.  If  there  is  a  problem  then  corrective  action  can  be 
taken. 
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10.  3. 10  Software  Requirements  Analysis 

It  is  critical  in  the  Requirements  Analysis  Phase  for  the 
engineering  staff  to  have  a  clear  understanding  of  what  the 
system  is  required  to  do.  Once  the  requirements  are  known,  the 
engineer  can  begin  to  conduct  feasibility  studies,  benchmark 
testing,  and  simulations  to  verify  and  identify  those 
requirements  that  can  be  met  and  those  that  have  risk 
associated  with  them.  Because  of  the  overhead  associated  with' 
the  use  of  Ada  interrupts  it  is  critical  that  in  this  phase 
engineers  begin  to  identify  how  critical  is  the  overhead  in 
terms  of  meeting  specific  requirements.  If  it  is  determined 
that  they  cannot  meet  the  requirements  either  with  their 
current  design  because  of  Ada  tool  set  limitations  or  because 
of  the  Ada  language  itself,  corrective  action  must  be  taken 
early.  Again,  when  using  Ada,  design  engineers  must  be 
particularly  careful  to  verify  that  the  requirements  can  be  met 
with  the  current  Ada  tool  set. 

10.  3.  13.  Preliminary  Design 

The  Preliminary  Design  Phase  should  be  based  on  sound 
information  developed  in  the  Requirements  Analysis  Phase.  If 
there  is  a  lack  of  knowledge  regarding  high  risk  elements  of 
the  system,  such  as  inter-  rupt  overhead,  the  preliminary 
design  of  the  system  can  be  seriously  impacted.  If  the  problem 
of  interrupt  overhead  is  not  discovered  until  this  phase, 
corrective  action  must  be  taken  to  reduce  the  risk  of  failure. 
This  may  mean  a  change  in  the  system  requirements  or  a  modified 
approach  to  the  system  design.  The  longer  a  problem  goes 
undetected  the  more  costly  it  will  be  to  resolve  the  problem  in 
the  later  phases. 

10. 3. 12  Detail  Design 

As  in  the  Preliminary  Design  Phase,  the  Detail  Design  Phase 
must  be  based  on  sound  information  from  the  prior  phases.  The 
impact  that  interrupt  overhead  can  have  on  the  detail  design  of 
a  system  can  result  in  a  complete  redesign  of  the  system.  This 
could  cause  major  cost  impacts  and  schedule  slippages.  However, 
if  no  simulation  or  prototypes  have  been  built  to  verify  the 
design  approach,  major  problems,  such  interrupt  overhead,  can 
go  unseen  in  the  Detailed  Design  phase.  Depending  on  the.  nature 
of  the  problem  the  project  could  be  beaded  for  failure  if 
neither  the  hardware  design  nor  the  software  design  considers 
the  problem. 
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10. 3. 13  Personnel  Resources 

With  regard  to  Personnel  Resources*  the  problem  o£  interrupt 
overhead  will  not  create  a  major  problem  if  the  risk  analysis 
is  done  early  in  the  software  development  cycle.  However*  if 
the  problem  is  not  identified  until  the  Detailed  Design  Phase* 
additional  personnel  may  be  required  to  modify  the  design  and 
stay  on  schedule. 

If  special  optimization  is  required  to  the  Ada  tool  set* 
specialists  may  be  required. 

10.  3. 14  Cost 

As  discussed  in  earlier  sections  of  this  problem  (Impact  of 
Interrupt  Overhead  On  System  Performance}*  major  cost  impact 
can  be  incurred  by  a  project.  Interrupts  play  a  critical  role 
in  the  design  of  embedded  systems.  The  later  in  the  development 
cycle  the  problem  is  discovered*  the  more  costly  xt  will  be  to 
resolve  the  problem. 

10.  3. 15  "  Schedule 

Schedule  impact  will  be  determined  by  how  severely  the 
interrupt  overhead  will  affect  the  design  of  the  system  and  how 
many  extra  resources  a  project  must  have  to  resolve  the 
problem.  If  the  problem  is  severe  and  the  project  lacks  the 
required  resources*  schedule  intact  will  occur.  Of  course*  the 
longer  the  problem  goes  unresolved  the  greater  the  schedule 
slippage  can  be. 
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10.  4  IMPACT  OF  MEMORY  MAKAGEMENT  OVERHEAD 

The  run-time  support  provided  to  Ada  applications  programs  by 
the  Ada  RSL  includes  a  number  of  memory  management  functions. 
The  primary  funccions  are  memory  allocation  and  deallocation 
and  heap  storage  management  (garbage  collection).  These 
functions  are  performed  by  the  RSL  either  on  an  as  needed  basis 
(memory  allocation/deallocation  during  a  context  switch)  or  as 
required  by  the  application  (use  of  access  types  to  create 
objects  at  run-time). 

However,  the  RSL  memory  management  features  add  a  significant 
amount  of  run-time  overhead  to  the  performance  of  an  .  Ada 
system.  Since  these  functions  are  resident  in  the  target 
machine  and  operate  in  conjunction  with  the  application 
programs,  they  also  require  system  resources  (CPU, memory ) .  The 
utilization  of  system  resources  by  the  RSL  must  be  addressed 
when  performing  overall  system  sizing  and  timing  analyses  in 
the  applications  environment.  It  is  important  to  know  whether 
the  overhead  associated  with  the  RSL  memory  management  features 
is  large  enough  to  affect  the  ability  of  the  system  to  meet 
specified  requirements. 

10.  4.  1  Efficiency 

Use  of  the  memory  management  features  of  the  RSL  can 
significantly  increase  system  overhead  while  reducing  overall 
system  efficiency.  The  Ada  memory  management  features  utilize 
system  resources  -  CPU  time  to  perform  the  functions  and 
storage  for  the  memory  management  software  within  the  RSL.  The 
memory  management  software  is  resident  in  the  target  machine 
and  operates  in  conjunction  with  the  applications  softwue. 
Thus,  the  memory  management  software  contends  with  the 
applications  programs  for  access  to  system  resources  (CPU  and 
memory).  Thus,  when  estimating  or  assessing  system  resource 
utilization,  the  resource  requirements  due  to  memory  management 
overhead  must  be  addressed. 

10.  4.  2  Correctness 

The  RSL  memory  management  software  resides  in  the  target 
environment  and  operates  in  conjunction  with  the  applications 
programs.  Thus,  it  is  essential  that  the  correctness  of  the 
memory  management  software  for  a  particular  application  be 
verified  as  part  of  the  overall  system  verification, 
validation,  and  acceptance  process.  This  will  probably  require 
some  support  from  the  compiler'  vendor  since  the  memory 
managrment  software  is  pre-packaged  and  delivered  as  part  of 
the  RSL. 
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10.  4.  3  Verifiability 

The  programs  which  perform  the  Ada  memory  management  functions 
reside  in  the  target  environment  (within  the  RSL}  and  operate 
at  runtime  in  conjunction  with  the  applications  programs. 
While  attempting  to  isolate  errors  found  during  the  system 
debugging  and  testing  process,  the  performance  and  correct 
operation  of  the  memory  management  software  must  be  verified 
along  with  that  of  the  applications  programs.  This  can  prove 
to  be  difficult,  since  it  involves  verifying  and  debugging 
software  that  the  applications  programmers  are  generally 
unfamiliar  with. 

10.  4.  4  Security 

The  Ada  memory  management  functions  performed  by  the  RSL  can 
have  a  significant  impact  on  system  security.  The  RSL  memory 
management  functions  are  performed  at  run-time  in  conjunction 
with  >the  operation  of  the  applications  programs. 

For  an  application  which  involves  classified  processing,  it  is 
important  to  control  the  access  to  classified  programs  and  data 
by  all  software  that  is  resident  in  the  target  environment, 
including  the  RSL  memory  management  software.  If,  for  example, 
the  RSL  memory  management  software  performs  garbage  collection 
in  an  area  of  memory  where  classified  data  is  stored,  it  is 
passible  that  the  classified  data  could  be  corrupted. 

Currently,  it  does  not  seem  to  be  possible  to  prevent  the  RSL 
from  accessing  particular  portions  of  memory  (where  secure 
information  may  be  stored)  without  providing  special  protection 
methods.  These  methods  could  include  the  use  of  a  software 
kernel  or  special-purpose  hardware  to  control  access  to 
protected  memory  locations. 

The  implementation  of  methods  such  as  these  could  require 
significant  modifications  to  the  RSL.  Since  the  RSL  memory 
management  functions  are  pre-packaged  within  the  RSL,  these 
modifications  would  probably  have  to  be  implemented  by  the 
compiler  vendor. 

10.  4.  5  Benchmark 

To  develop  a  complete  euid  accurate  estimate  of  performance  for 
an  Ada  system,  the  run-time  overhead  due  to  the  memory 
management  features  must  be  assessed.  To  obtain  a  clear 
picture  of  expected  performance  for  the  RSL  memory  management 
functions,  benchmark  data  should  be  gathered.  The  compiler 
vendor  and  other  applications  developers  (if  available)  should 
be  contacted  to  supply  as  much  of  this  data  as  possible  based 
on  performance  estimates  and  actual  experience. 
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However,  two  main  problems  exist  in  obtaining  this  data. 
First,  the  data  that  is  obtained  from  the  compiler  vendor  and 
applications  developers  may  not  reflect  the  expected  memory 
usage  characteristics  for  the  Ada  system  being  developed.  Some 
(extensive)  interpolation  will  probably  be  required.  Secondly, 
obtaining  application-specific  benchmark  data  for  the  memory 
management  features  is  very  difficult  due  to  the  unfamiliarity 
of  the  applications  developer  with  the  RSL . code.  This  effort 
will  probably  require  the  assistance  of  the  con^iler  vendor. 

10.  4.  6  Simulation 

To  Obtain  a  complete  and  accurate  of  system  performance  for  an 
Ada  system,  an  end-to-end  system  simulation  should  be 
performed.  The  model  of  the  Ada  system  being  developed  should 
include  the  effects  of  the  run-time  memory  management  features. 
However,  most  Ada  applications  developers  are  not  familiar 
enough  with  the  operation  of  the  RSL  memory  management  features 
to  develop  an  effective  simulation.  To  do  this  will  probably 
require  support  from  the  compiler  developer. 

10.  4.  7  Optimization 

uue  to  the  current  state  of  the  available  Ada  tools,  the 
performance  of  Ada  software  systems  is  a  major  issue.  The  poor 
Ada  system  performance  is  prim^urily  due  to  the  inefficiency  of 
the  generated  Ada  code  and  the  extensive  overhead  associated 
with  the  run-time  functions  performed  by  the  RSL.  One  of  the 
typical  solutions  to  this  problem  is  to  perform  extensive  Ada 
system  optimization. 

To  combat  the  additional  overhead  and  potential  security 
problems  (controlled  access  to  progreuss  and  data)  due  to  the 
RSL  run-time  memory  management  features,  system  optimization 
may  be  required.  This  optimization  may  include  modifications 
to  the  RSL  memory  management  software  to  increase  its  execution 
speed,  decrease  its  program  size,  and  build  in  memory  access 
controls.  Because  most  applications  developers  are  unfamiliar 
with  the  operation  of  this  RSL,  this  effort  would  probably 
require  support  from  the  compiler  vendor. 

10.  4.  3  System  Sizing 

When  performing  system  sizing  estimates,  the  RSL  memory 
management  features  play  two  important  roles.  First,  this 
software  resides  in  the  target  environment  and  operates  in 
conjunction  with  the  applications  progreuas.  Thus,  the  amount 
of  memory  space  that  it  requires  must  be  Included  in  the  system 
sizing  estimates.  One  typical  system  optimization  technique  is 
to  remove  from  the  RSL  those  memory  management  features  which 
are  not  required  for  a  particular  application. 
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Secondly,  the  RSL  provides  memory  -management  features  which  can 
be  critical  for  real-time  embedded  systems,  such  as  memory 
allocation/deallocation  and  heap  storage  management  (garbage 
collection).  For  example,  the  memory  deallocation  feature 
could  conceivably  reduce  the  amount  of  system  memory  required 
to  execute  the  applications  programs  by  allowing  the  programs 
to  deallocate  memory  areas  as  soon  as  they  have  finished 
processing  them.  But  this  advantage  could  be  offset  by  the 
additional  memory  required  to  perform  the  memory  deallocation 
function. 

Detailed  systems  analysis  should  be  performed,  in  conjunction 
with  the  compiler  vendor,  to  determine  the  overall  impact  of 
the  RSL  memory  management  features  on  system  sizing. 

10.  4.  9  System  Timing 

When  performing  system  timing  estimates,  the  RSL  memory 
management  features  play  two  important  roles.  First,  the  RSL 
memory  management  software  resides  in  the  target  environment 
and  operates  at  run-time  in  conjunction  with  the  applicationb 
programs.  Thus,  the  execution  time  required  for  the  memory 
management  software  must  be  included  in  the  system  timing 
estimates.  One  typical  optimization  technique  is  to  remove 
from  the  RSL  those  memory  management  functions  which  are  not 
required  for  a  particular  application. 

Secondly,  the  RSL  memory  management  features  can  be- critical 
for  the  development  of  real-time  embedded  applications.  These 
features  include  memory  allocation/deallocation  and  heap 
storage  management  (garbage  collection).  For  example, 
performing  garbage  collection  could  conceivably  improve  system 
performance  by  merging  non-contiguous  areas  of  memory  and 
providing  sufficient  memory  to  begin  execution  of  a  program 
earlier  than  would  have  occurred  otherwise.  But  these 
advantages  must  be  weighed  against  the  additional  system 
overhead  associated  with  the  memory  metnagement  features. 

Detailed  systems  analysis  should  be  performed,  in  conjunction 
with  the  compiler  vendor,  to  determine  the  overall  impact  of 
the  RSL  memory  management  features  on  .«ystem  timing. 


10.  4.  10  Vendor  Interface 

To  ensure  that  the  memory  management  functional  and  performance 
issues  are  addressed  in  the  overall  system  design,  the 
applications  developer  must  establish  a  close  relationship  with 
the  compiler  vendor.  This  is  doubly  important  since  the 
sometimes  extensive  Ada  system  optimization  tasks  may  require 
support  from  the  compiler  vendor  and/or  modifications  to  the 
compiler  or  RSL. 


3  28 


REAL-TIME  ADA  PROBLEM  STODY 


10/  9/  87 


For  example,  the  compiler  can  be  a  valuable  source  of  memory 
management  benchmarking  data  for  use  in  performing  system 
sizing  and  timing  analyses.  The  compiler  vendor  can  also 
provide  support  to  the  applications  developers  during  system 
optimization  and  will  be  required  to  make  any  necessary  changes 
to  the  compiler  and/or  RSL  in  conjunction  with  the  development 
effort. 

10.  4. 11  Prototype 

To  validate  the  system  design  and  evaluate  system  performance, 
the  application  developer  should  build  a  prototype  of  the  Ada 
system  under  development.  The  prototype  should  contain  the 
actual  system  hardware  and  system  software  (compiler  and  RED 
and  should  implement  critical  system  functions. 

This  prototype  should  be  used  to  determine  the  actual  system 
impact  of  the  RSL  memory  management  overhead  and  compare  this 
to  expected  results.  The  prototype  should  also  be  used  to 
evaluate  the  effect  on  memory  mauiagement  overhead  of  changes  to 
the  hardware,  system  software,  and  applications  software. 

10.  4.  12  Con^ilet 

For  particular  Ada  applications,  the  overhead  resulting  from 
the  RSL  run-time  memory  management  features  may  require  system 
optimization  to  be  performed.  This  optimization  may  include 
modifications  to  the  RSL  to  remove  unwanted  sections  of  the  RSL 
memory  management  software,  to  add  required  functions  (such  as 
controlled  memory  access),  or  to  improve  its  efficiency 
(reduced  execution  time  and  memory  requirements). 

If  required,  these  changes  must  be  designed  and  implemented  by 
the  compiler  vendor  with  support  from  the  applications 
developer  to  ensure  that  the  changes  are  as  requested.  The 
changes  must  then  be  tested  (via  prototype)  to  evaluate  their 
performance.  The  system  documentation  must  be  updated  to 
reflect  these  changes. 

10.  4. 13  Software  Requirements  Analysis 

During  the  Software  Requirements  Analysis  Phase,  information 
concerning  the  performance  and  functionality  of  the  RSL  memory 
management  features  should  be  provided  to  the  applications 
developers  to  support  preliminary  system  sizing,  timing,  and 
functional  analyses.  The  results  of  these  analyses  should 
identify  potential  problem  areas  to-be  addressed  as  part  of  the 
system  design  effort.  If  this  data  is  not  made  available 
during  the  Software  Requirements  Analysis  Phase,  the  results  of 
the  system  ainalyses  will  not  be  accurate.  This  could  result  in 
severe  problems  during  the  system  design  and  implementation 
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phases  in  areas  such  as  desig^i  rework,  requirements  for 
additional  hardware  and  software,  extensive  system 
optimization,  and  system  security. 

10.  4. 14  Preliminary  Design 

During  the  preliminary  design,  the  result  of  the  software 
requirements  analysis  efforts  are  used  to  develop  a  preliminary 
system  design.  The  performance  and  functional  capabilities  of 
the  RSL  memory  management  software  must  be  made  available  to 
the  system  designers  to  support  their  efforts.  This 
information  is  evaluated  to  determine  its  impact  on  system 
hardware  selection,  system  sizing  and  timing  estimates,  and 
selection  of  an  Ada  compiler  and  support  software  tools.  The 
results  of  the  preliminary  design  efforts  may  also  identify 
potential  areas  where  the  RSL  memory  management  features  must 
be  modified  to  meet  system  requirements.  If  these  areas  are 
not  identified  as  early  as  possible  in  the  system  development 
cycle,  they  could  critically  impact  the  entire  project,  since 
they  must  be  implemented  by  the  compiler  vendor  in  parallel 
with  the^  development  effort. 

10.  4.  15  Detail  Design 

During  the  detailed  design  effort,  detailed  system  sizing  and 
timing  estimates  should  be  available  which  include  the  overhead 
due  to  the  memory  management  features.  Any  required  design 
changes  to  the  compiler  and  RSL  memory  management  software 
should  be  incorporated  into  the  overall  system  design.  A 
prototype  of  the  Ada  system  should  be  built  to  verify  the 
functional  capabilities  and  the  accuracy  of  the  sizing  and 
timing  estimates  for  the  RSL  memory  management  software. 

If  these  activities  are  not  performed,  the  implementation  and 
testing  efforts  could  be  impacted  due  to  performance  problems 
related  to  the  memory  management  features.  This  could  result 
in  extensive  design  rework  in  order  to  meet  system  performance 
requirements. 
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10.  5  IMPACT  OF  RON-TIME  SUPPORT  LIBRARY  CK7ERHEAD  ON  SYSTEM 
PERFORMANCE 

The  Runtime  Support  Library  (RSL)  is  the  total  package  o£ 
software  required  at  run-time  to  support -the  execution  of  the 
object  code  generated  by  the  compiler  for  the  application 
program.  Functions  such  as  dynamic  memory  management,  system 
activation/allocation,  interrupt  processing,  input/output 
operations,  co-processor  support,  and  tasking  are  all  performed 
by  the  RSL.  The  basic  problem  with  the  RSLs  of  today  is  that 
they  are  generally  too  large  and  too  slow  for  many  embedded 
system  applications.  In  terms  of  sizing,  the  problem  is  more 
noticeable  when  the  application  program  is  fairly  small.  In 
this  case,  it's  very  possible  that  the  RSL  can  be  larger  than 
the  application  program.  As  the  .application  programs  grow 
larger,  the  proportion  of  memory  taken  by  the  RSL  become  less, 
thus  the  impact  is  not  as  great.  For  timing  impacts,  the 
amount  of  overheao  experienced  will  depend  upon  what  features 
of  the  language  are  used.  Generally  speaking,  the  more  you 
use  the  unique  features  (tasking,  dynamic  memory,  delays,  etc.  ) 
of  Ada,  the  more  over-head  that  is  incurred.  This  can  be 
attributed  in  part  to  the  immaturity  of  existing  RSLs. 
Because  some  of  the  Ada  features  are  new  to  the  implementors  of 
the  language,  the  techniques  of  implementing  them  efficiently 
are  still  emerging. 

As  an  example  of  what  some  contractors  are  experiencing  in  RSL 
overhead,  on  Sonicraft's  MEECN  (Minimum  Essential  Emergency 
Communications  Network)  project  it  was  discovered  that  the  RSL 
alone  would  require  over  ninety  kilobytes  (KB).  Of  course, 
optimization  efforts  had  to  begin  immediately  to  reduce  size 
since  the  system  was  limited  in  its  memory  and  power  usage. 

10.  5.  1  Efficiency 

The  overhead  associated  with  the  Run-Time  Support  Library  will 
impact  the  efficiency  of  embedded  systems  in  terms  of  sizing 
and  timing.  Because  of  the  inefficiencies  of  the  RSL,  embedded 
systems  today  will  utilize  more  memory  (RAH,  ROM)  and  execute 
programs  slower. 

10.  5.  2  Bencbaazk 

Good  benchmark  testing  of  the  Run-time  Support  Library  (RSL)  is 
a  must  to  insure  the  successful  design  and  development  of  an 
embedded  system  using  Ada*  All  aspects  of  RSL  overhead  problems 
must  be  identified  and  done  so  as  early  in  the  software 
development  cycle  as  possible.  For  without  this  critical 
information  designers  will  design  the  system  based  on  faulty 
information  or  the 'lack  of  information.  This  can  lead  to  major 
cost  and  schedule  impacts,  if  not  the  complete  failure  of  the 
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system  to  performance.  If  the  contractor  cannot  obtain  the 
required  benchmark  test  results  from  the  developer  of  the  Ada 
tool  set,  they  must  conduct  benchmark  testing  themselves. 

10.  5.  3  Simulation 

To  verify  that  the  RSL  overhead  problems  will  not  cause  a 
problem  in  one's  design  approach,  one  must  conduct  simulations 
of  the  system.  This  will  help  identify  the  RSL  overhead 
problems  that  are  a  risk  to  the  project.  Problems  such  a  sizing 
and  timing  are  critical  to  the  development  of  the  system.  If 
the  sizing  and  timing  requirements  of  the  RSL  are  not 
discovered  until  the  Detailed  Design  Phase  major  cost  and 
schedule  impact  can  be  incurred  by  both  software  and  hardware. 

10.  5.  4  Optimization 

If  through  benchmark  testing  and  simulation  it  is  discovered 
that  optimization  is  required,  one  may  find  this  to  be  very 
expensive.  This  is  because  the  Run-Time  Support  Library  is 
larger  and  more  complex  than  in  other  high  languages.  Usually 
the  contractors  cannot  modify  the  RSL  themselves,  so  they  have 
to  contract  the  vendor  to  perform  the  optimizations. 

When  Sonicraft  discovered  that  the  size  of  the  RSL  was  over 
ninety  kilobytes,  we  began  to  investigate  optimization 
solutions.  It  was  determined  that  one  of  the  major  size  drivers 
was  the  fact  that  major  portions  of  the  RSL  was  written 

in  Ada.  Since  the  Ada  compiler  was  very  inefficient  it 
produced  a  very  large  RSL.  The  solution  was  to  rewrite 

much  of  the  RSL  in  assembly  language. 

10.5.5  System  Siziug 

The  problem  of  having  RSL  overhead  will  directly  affect  the 
system  sizing.  Because  the  RSL  is  inefficient  it  will  require 
more  code  to  perform  a  particular  function.  This  means  more 
memory  is  required  for  the  systesk  To  avoid  a  situation  where 
the  application  program  will  not  fit  into  the  available  system 
memory,  one  must  conduct  simulations  and  possibly  build  a  rapid 
prototype.  By  doing  so,  problems  will  be  identified  early  in 
the  development  cycle  and  corrective  action  can  be  taken. 

10.  5.  6  System  Timing 

To  determine  how  the  RSL  overhead  problems  will  affect  the 
system  timing  requirements,  one  will  have  to  built  a  rapid 
prototype  of  the  real  embedded  system.  This  will  allow  the 
design  engineers  to  examine  the  timing  of  the  system  and 
determine  what  problems  may  exist.  As  soon  as  problems  with 
regard  to  timing  are  known,  the  chances  the  project  will  have 
for  successful  completion  within  cost  and  schedule  can  be 
known. 
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A  key  problem  that  affects  the  system  timing  is  the  RSL's 
ability  to  process  interrupts  efficiently.  Please  refer  to 
problem  number  three  for  a  more  detailed  discussion  of  this 
problem. 

10.  5.  7  Prototype 

As  referred  to  in  the  System  Timing  section  for  this  problem  a 
rapid  prototype  may  be  required  to  identify  what  impacts  the 
RSL  overhead  problems  will  have  on  the  requirements  of  a 
particular  systenw  The  earlier  the  problems  are  identified  the 
sooner  corrective  action  can  be  taken  to  resolve  the  problem. 

10.  5.  8  Compiler 

There  is  a  direct  connection  between  the  overhead  problems  of 
the  Run-Time  Support  Library  and  the  Ada  Compiler.  The 
connection  is  that  much  of  the  RSL  is  written  in  Ada  and,  as 
discussed  in  problem  number  seven,  the  Ada  compilers  of  today 
produce  inefficient  object  code.  So  when  the  run-time  code  is 
compiled  by  an  inefficient  compiler,  the  result  is  a  large, 
inefficient  RSL.  As  2m  optimization  solution  to  the  problem  of 
having  a  large  RSL,  Sonicreift  contracted  the  vendor  to  rewrite 
portions  of  the  RSL  in  Intel  assembly  language.  This  way  less 
of  the  RSL  code  was  produced  by  the  Ada  compiler  and  some 
degree  of  size  reduction  was  obtained. 

10.  5.  9  Software  Requiresicnts  Analysis 

In  the  Software  Requirements  Analysis  Phase  the  engineering 
staff  must  have  a  clear  understanding  of  what  the  system  is 
required  to  do.  Once  the  requirements  are  known,  the  engineer 
can  begin  conducting  feasibility  studies,  benchmark  testing, 
and  simulations  to  verify  and  identify  those  requirements  that 
can  be  met  and  those  that  have  risk  associated  with  them.  The 
overhead  impacts  associated  with  the  Run-time  Support  Library 
make  it  critical  that  in  this  phase  engineers  begin  to  identify 
how  critical  is  the  overhead  in  terms  of  meeting  the  system 
requirements  in  software  vs.  hardware.  If  it  is  determined  that 
they  cannot  meet  the  requirements  because  of  the  current 
design,  the  RSL,  or  the  Ada  language  itself,  corrective  action 
must  be  taken  early.  This  task  may  demand  that  training  to 
understand  RSL  operation  be  obtained. 

10.5.10  Preliainary  Design 

The  Preliminary  Design  Phase  should  be  based  on  sound 
information  developed  in  the  Software  Requirements  Analysis 
Phase.  A  lack  of  knowledge  regarding  high  risk  elements  of  Ada, 
such  as  run-time  support  impacts,  can  jeopardize  the 
preliminary  design  of  the  system.  If  the  problems  of  run-time 
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overhead  are  not  discovered  until>  this  phase,  it  will  be  more 
costly  to  take  needed  corrective  action.  This  may  mean  a 
change  in  the  system  requirements  or  a  redesign  of  the  run-time 
code.  The  longer  a  problem  goes  undetected  the  more  costly  it 
will  be  to  resolve  the  problem  in  the  later  phases. 

10.  5.  11  Detail  Design 

The  Detail  Design  Phase  must  be  based  on  sound  information  from 
the  prior  two  phases.  The  impact  that  run-time  overhead  can 
have  on  the  detail  design  of  a  system  can  result  in  the 
complete  failure  of  the  system  to  perform  to  specifications. 
This  can  cause  major  cost  impacts  and  schedule  slippages. 
Again,  if  no  simulations  or  prototypes  have  been  built  to 
verify  the  design  approach,  major  problems,  such  as  run-time 
overhead  problems,  can  go  unseen  in  the  Detailed  Design  Phase. 
Depending  on  the  nature  of  the  problems  the  project  could  be 
headed  for  failure  since  it  is  the  RSL  that  is  controlling  most 
of  the  execution  of  the  application  program  at  run-time. 
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10.  6  IMPACT  OF  TASKING  OVBRBBAD  ON  SYSTEM  PERFORMANCE 

One  of  the  key  features  of  the  Ada  language  is  tasking.  Ada 
tasks  are  "entities  whose  executions  proceed  in  parallel  [REF. 

11.  "This  feature  gives  Ada  a  great  advantage  or  other  high- 
level  languages^  but  not  without  a  price.  The  cost  is  in  terms 
of  overhead.  Tasking  overhead  affects  the  efficiency  of  the 
system  in  both  sizing  and  timing. 


Whenever  a  designer  decides  to  utilize  tasking  in  an  Ada 
program,  he  will  automatically  incur  an  additional  cost  in 
terms  of  additional  run-time  support  code,  which  can  be  as  high 
as  thirty  kilobytes.  This  code  is  required  to  perform  the 
various  features  (entry  calls,  accepts,  selects, ..  etc.  )  of  Ada 
tasking  at  run-time.  Another  sizing  problem  has  to  do  with  the 
stack  requirements  of  tasks.  The  designer  must  allocate  enough 
memory  for  his  application  to  make  available  the  additional 
stack  memory  for  task  control  information.  Also,  any  stack 
memory ' required  for  any  run-time  procedures  called  to  execute  a 
particular  feature  must  be  added  to  the  total  size  of  the  task 
stack  allocation.  The  stack  allocation  requirements  are 
required  for  each  task  declared  in  the  designer's  application 
program.  Thus,  the  problem  is  compounded. 

With  the  use  of  tasking,  today's  applications  will  experience 
timing  overhead  impacts  due  to  tasking  features  like  task 
allocation,  task  activation/termination,  task  switching, 
synchronization  and  task  rendezvous.  To  determine  what  kind  of 

overhead  would  be  incurred  by  using  tasking,  a  study  was 

performed  by  Hughes  Aircraft  Company.  The  study  conducted  a 

series  of  tests  using  the  DEC  Ada  Compiler  (1.2}  on  a  VAX  8600 
(VMS  4.  2).  The  following  results  show  the  magnitude  of  task 
overhead  compared  to  the  processing  done  within  the  task 

itself. 
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Task 

Normal 

Description 

Overhead 

Proc. 

(usee) 

(usee) 

1.  Task  activation  and  termination 

1960 

17  8 

2.  Task  created  via  an  allocator 

150 

14 

3.  Producer-Consumer  (2  task  switches) 

503 

46 

4.  Producer-Buffer-Consumer 

1220 

111 

5.  Producer -Buff er-Transporter-Consumer 

16  94 

154 

6.  Producer-Transpt-Buf f er-Transpt-Consumer 

2248 

204 

7.  Relay 

906 

82 

8.  Conditional  Entry 

-  no  rendezvous 

17  0 

15 

-  rendezvous 

29 

3 

9.  Timed  Entry 

-  no  rendez  vous 

254 

23 

-  with  rendezvous 

33 

3 

10.  Selective  Wait  with  Terminate 

127 

12 

11.  Exception  during  a  rendezvous 

962 

87 

[Ref]  T.  M.  Burger  and  K.  W.  Nielsen,  "An 

Assessment  of  the 

Overhead  Associated  with  Tasking  Facilities 

and  Task 

Paradigms 

in  ADA”,  Hughes  Aircraft  Company. 

10.  6.  1  Efficiency 

Because  of  the  tasking  overhead  in  Ada  today,  many  embedded 
systems  will  try  to  avoid  the  inefficiencies  by  minimizing  or 
even  eliminating  the  use  of  tasking.  By  doing  so,  the  code  at 
the  Ada  source  level  may  be  inefficient  code,  since  the  tasking 
features  of  Ada  would  be  better  suited  for  these  particular 
functions.  However,  the  non-tasking  code  may  produce  smaller 
amounts  of  code  to  run  on  the  target  machine  because  this  code 
need  handle  only  the  special  case  at  hand. 

10.  6.  2  Benchoark 

Benchmark  testing  of  tasks  has  proven  to  be  difficult, 
partially  because  of  compiler  vendors  and  their  implementations 
of  tasking.  The  compiler  implementors  have  been  given  a  great 
deal  of  implementation  latitude,  and  as  a  result,  it  is 
difficult  to  develop  a  set  of  benchmarks  that  completely 
characterize  this  area.  However,  difficult  it  is  for  one  to 
test  the  characteristics  of  t.asking,  the  information  is 
urgently  needed  if  embedded  systems  are  be  developed  without 
unforeseen  impacts. 
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10. 6. 3  Simulation 

Simulations  of  embedded  system  designs  using  Ada  tasking  is 
required  for  a  number  of  reasons.  First,  the  concept  and  use  of 
Ada  tasking  in  embedded  system  design  is  new  to  many  of  today's 
Software  engineers.  As  a  result,  the  impact  of  using  tasks  can 
go  without  notice  and  result  in  major  cost  impacts. 

Second,  the  characteristics  of  the  compiler  with  regards  to 
tasking  may  be  vague  or  unknown,  thus  the.  simulation  will  help 
identify  problems  associated  with  the  use  of  tasking. 

Third,  the  simulation  provides  a  time  where  the  design  can  be 
optimized  to  avoid  the  overhead  impacts  of  tasking. 

On  Sonicraft's  MEECN  project  simulations  were  conducted  to 
determine  how  to  control  the  task  elaboration  and  activation 
process.  This  was  necessary  to  insure  the  proper  start-up  of 
the  system.  In  the  process,  it  was  discovered  that  the  task 
elaboration/activation  overhead  time  required  to  complete 
start-up  was  longer  then  the  time  period  for  the  system  power- 
up-fail  indicator,  as  a  result  system  design  modifications  were 
required. 

10.  6.  4  Optimization 

The  inability  of  todays  RSLs  to  handle  tasking  efficiently  will 
impact  many  embedded  system  projects  to  the  point  of  requiring 
special  optimization.  Such  wm  the  case  on  Sonicraft's  MEECN 
project,  an  Intel  80  86  based  system,  where  it  was  discovered 
that  task  switching  times  were  on  the  order  of  milliseconds. 
Special  optimization  of  Ada  compilers  will  often  require  the 
assistance  of  the  vendor.  Of  course,  this  increases  the  cost  to 
develop  the  system  using  Ada. 

10.  6.  5  System  Sizing 

Tasking  overhead  will  directly  affect  the  sizing  of  the  system. 
The  use  of  tasking  in  the  system  will  require  additional  run¬ 
time  support  code,  thus  more  ROM  memory  is  required.  The 
inefficient  use  of  stack  space  will  also  require  additional 
RAM.  An  example  of  this  is  the  "Null  Task"  used  in  the  8086 
ALS.  The  purpose  of  this  task  is  to  execute  when  no  other  task 
is  available  to  execute.  This  task  contains  virtually  no  code 
and  therefore  it  should  need  very  little  RAM.  However,  since 
it's  a  predefined  task  it  is  assigned  the  default  stack  size  of 
four  kilobytes  plus  two  kilobytes  additional  space  for  the 
handling  of  errors.  Thus,  you  have  six  kilobytes  allocated  for 
a  cask  that  does  virtually  nothing. 
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10.  6.  6  Systen  Timing 

As  in  system  sizing,  the  overhead  of  tasking  will  directly 
affect  the  system  timing.  As  the  number  of  tasks  increase  in 
the  design  so  will  the  overhead.  This  is  one  of  the  major 
reasons  why  embedded  system  designers  try  to  avoid  using 
tasking:  the  overhead  costs  both  in  terms  of  sizing  and  timing 
are  too  high. 

10.  6.  7  Prototype 

As  in  problem  number  five,  the  development  of  a  rapid  prototype 
to  prove  or  disprove  the  design;  is  an  excellent  way  of 
determining  how  tasking  overhead  will  impact  the  performance  of 
the  system.  Although  prototypes  can  be  expensive,  the  cost 
savings  obtainable  due  to  the  risks  associated  with  tasking 
makes  it  a  viable  option. 

10.  €. 3  Software  Requireaents  Analysis 

With  the  commitment  of  000  to  the  use  of  the  Ada 
language, contractors  must  perform  a  comprehensive  analysis  of 
their  requirements.  Many  of  today's  requirement  specifications 
are  written  with  the  mind  set  of  past  performance  in  embedded 
systems.  However,  with  the  Ada  mandate  firmly  supported,  the 
immaturity  of  Ada  compilers  versus  the  performance  expectations 
of  these  spec  writers  may  be  a  problem  for  now.  The  impact  of 
tasking  overhead  requires  the  system  to  have  more  memory,  and 
execution  speeds  are  currently  slow  in  areas  such  as  task 
switching.  These  impacts  may  require  that  the  system 
requirements  be  expanded  to  better  support  the  use  of  Ada. 
Other  options  may  be  to  continue  development  under  the 
restrictive  requirements  and  contract  to  have  the  tasking 
overhead  problem  optimized.  Clearly,  it  is  critical  that  the 
system  requirements  be  closely  reviewed  with  respect  to  the  use 
of  Ada. 

10. 6. 9  Preliminary  Design 

The  impact  that  tasking  overhead  :an  have  on  the  development  of 
a  preliminary  design  is  severe.  Because  this  is  the  case 
engineers  cannot  assume  that  Ada  tasking  will  execute  with  the 
speeds  they  are  accustomed  to.  Early  in  the  Preliminay  Design 
Phase  sizing  and  timing  au^alyses  must  be  conducted  to  reduce 
risk.  These  analyses  must  be  based  on  sound  benchmark  results 
on  the  compiler  and  simulation  results  on  the  system's  critical 
functions.  By  doing  so,  the  impact  of  tasking  overhead  can  be 
considered  in  the  preliminary  design  of  the  system. 
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10. 6. 10  Detail  Design 

At  this  point  in  the  development  cycle  the  impact  of  tasking 
overhead  can  cause  a  complete  redesign  of  the  system.  Tasking 
is  one  of  the  main  program  units  which  directly  affects  system 
timing.  Considering  that  interrupts  are  handled  by  tasks,  the 
degree  to  which  a  real-time  embedded  system  is  capable  of 
responding  to  real-time  events;  will  be  determined  in  part  by 
the  impact  that  tasking  overhead  has  on  the  system.  Again, 
analysis  should  be  conducted  prior  to  this  phase  to  avoid  major 
cost  and  schedule  impacts. 
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10.7  INEFFICIENCY  OF  OBJECT  CODE' GENERATED  BY  ADA  COMPILERS 

As  with  most  first  generation  compilers  for  new  languages,  the 
Ada  compilers  today  are  somewhat  inefficient  because  of  the 
complexity  of  the  Ada  language.  Unfortunately,  the  lack  of 
efficient  compilers  directly  impacts  the  development  of 
embedded  systems  today.  Embedded  systems  typically  have  very 
restrictive  requirements  on  sizing,  timing  and  power 

consumption.  Therefore,  any  inefficiencies  in  the  object  code 
generation  will  impact  the  cost  and  performance  of  the  typical 
weapon  system.  Because  the  compilers  are  producing  more  code 
than  required  to  implement  a  particular  function  the 
compilation  time  is  longer.  As  a  result,  it  takes  developers 
somewhat  longer  to  complete  the  coding  process.  This  means 
schedule  and  cost  impacts. 

10.7.1  Efficiency 

The  inefficiency  of  Ada  compilers  directly  affects  the 
efficient  execution  of  the  run-time  program.  E-'.bedded  system 
development  is  impacted  both  in  terms  of  memory  usage  and 
execution  speed.  One  of  the  chief  contributors  to  this  problem 
is  the  validation  process.  While  "validation  guarantees 
legitimate  Ada  code,  it  does  not  guarantee  performance"  [REF 
1].  As  a  result  there  are  many  validated  compilers  today  that 
are  production  quality,  with  production  quality  meaning:  a 
compiler  capable  of  producing  machine  code  that  does  not 
greatly  exceed  that  obtained  from  a s s emb ly - 1  an g u a g e 
programming,  and  the  execution  speed  of  this  code  must  be 
comparable  to  that  of  assembly-language  machine  code. 

[Ref]  W,  Myers,  "Ada:  First  Users  -  Pleased;  Prospective  Users 
-  Still  Hesitant",  Computet,  1984. 

10.  7.  2  Bencbnask 

As  a  consequence  of  the  lack  of  high  quality  ACVC  tests  to 
provide  embedded  system  designers  with  any  test  results  on  the 
performance  characteristics  of  Ada  compilers,  it  has  been 
necessary  for  the  embedded  designer  to  either  develop  or 
contract  the  development  of  benchmark  testing  of  Ada  compilers. 


10.7.3  Simulation 

Due  to  the  impact  of  the  inefficient  object  code  generated  by 
todays  Ada  compilers,  embedded  system  designers  must  develop 
and  conduct  comprehensive  simulations  of  their  critical 
functions  to  verify  they  can  meet  the  requirements. 
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10.7.4  Optimization 

The  impact  that  the  inefficient  compiler  has  on  an  embedded 
project  is  the  requirement  to  optimize.  Either  the  embedded 
designer  spends  time  optimizing  his  design  as  a  consequence  of 
the  compiler  or  the  compiler  itself  is  optimized.  Both  can  be 
very  expensive. 

10.7.5  System  Sizing 

System  sizing  is  directly  impacted  by  the  inefficient 
generation  of  object  code.  This  will  impact  the  amount  of 
memory  required  in  the  system,  power  consumption  and  system 
reliability.  Whenever  possible  the  designers  may  take 
shortcuts,  such  as  the  Inclusion  of  assembly  language,  to 
obtain  a  reduction  in  memory,  which  can  lead  to  less 
maintainable  code. 

10. 7. 6  System  Timing 

Inefficient  object  code  mainly  affects  system  timing  due  to 
added  overhead  time  caused  by  the  execution  of  the  unneeded 
code.  In  some  cases  the  added  overhead  can  cause  the  system  to 
perform  poorly  in  response  to  real-time  events. 

10.7.7  Coiiq)iler 

The  problem  of  the  inefficient  Ada  compiler  is  probably  the 
most  discussed  problem  in  the  Ada  community.  The  reason  for 
this  is  that  the  compiler  is  one  of  the  first  (and  one  of  the 
most  used)  tools  needed  to  make  the  software  a  reality.  If  the 
compiler  does  not  work  properly  or  works  inefficiently/  the 
project  is  immediately  impacted.  Such  is  the  case  with  many  of 
the  validated  compilers  today.  Some  of  the  common  problems  are; 
slow  compilation  speed,  poor  diagnostics,  failure  of  valid  Ada 
constructs  and  inefficient  object  code  generation. 
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10.  8  NEED  FOR  EXTENSIVE  ADA  OPTIMIZATION 

Due  to  the  inefficiency  of  compiler-generated  Ada  applications 
code  and  the  excessive  overhead  associated  with  the  RSL  run¬ 
time  support,  extensive  optimization  is  generally  required  to 
improve  the  performance  of  Ada  systems. 

The  types  of  system  optimization  that  are  performed  include: 

*  Customizing  the  RSL  for  a  particular  application 

*  Reducing  RSL  overhead  (tasking,  memory  management, 
interrupts) 

*  Adding  special-purpose  hardware  and  software 

*  Rewriting  applications  programs  (algorithms) 

*  Modifying  compiler  implementation  details 

*  Using  non-Ada  software 

*  Providing  absolute  addressing  capability 

*  Providing  for  storage  of  constants  in  ROM 

However,  this  extensive  optimization  can  adversely  affect 
system  performance  and  project  productivity.  The  addition  of 
special-purpose  hardware  and  software  along  with  the  use  of 
project-specific  programs  can  reduce  system  portability, 
reliability,  maintainability,  reusability,  and  verifiability, 
and  can  increase  system  complexity.  Also,  the  extensive  rework 
that  is  performed  as  part  of  the  optimization  efforts  can 
decrease  overall  project  productivity. 

10.  8.  1  Reliability 

As  a  result  of  the  extensive  optimization  that  is  sometimes 
required  during  the  development  of  Ada  systems,  the  overall 
system  reliability  can  be  reduced.  This  is  due  to  the  fact  that 
system  changes,  particularly  when  made  to  a  complex  system,  can 
impact  other  areas  of  the  system  in  subtle  ways  that  are  only 
discernible  under  certain  conditions.  System  problems  that  are 
related  to  these  changes  may  only  occur  in  times  of  system 
stress  or  when  a  very  specific  series  of  events  occurs.  If 
^h*se  situations  are  not  identified  and  corrected,  the  overall 
system  reliability  is  reduced.  Comprehensive  regression 
testing  must  be  performed  as  part  of  the  system  optimization 
process  to  minimize  the  adverse  impact  on  system  relieibility. 

10.  8.  2  Maintenance 

As  a  result  of  the  extensive  system  optimization  that  is 
performed  during  the  development  of  real-time  embedded  Ada 
systems,  overall  system  maintainability  can  be  reduced.  This 
is  due  to  the  increase  in  overall  system  complexity  that 
generally  accompanies  the  optimization  process.  The  increase  in 
system  complexity  makes  the  operation  of  the  system  more 
difficult  to  understand  and  thus  reduces  system 
maintainability. 
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10.  8.  3  Verifiability 

The  extensive  system  optimiration  that  is  sometimes  performed 
in  the  development  of  Ada  systems  can  adversely  impact  the 
verifiability  of  the  system.  This  is  due  to  the  increase  in 
system  complexity  that  occurs  as  a  result  of  the  optimization 
efforts.  The  increase  in  system  complexity  makes  it  more 
difficulty  to  test  the  system  and  to  verify  that  the  system  is 
meeting  its  requirements. 

10.  8.  4  Portability 

The  extensive  system  optimization  that  is  performed  during  the 
development  of  Ada  systems  can  reduce  system  portability.  A 
number  of  the  changes  that  are  implemented  during  the  system 
optimization  process  provide  enhanced  performance  or 
functionality  for  a  specific  application.  This  is  usually  done 
by  taking  advantage  of  implementation  dependencies  in  the 
target'  machine  or  system  software  or  by  adding  special-purpose 
hardware  and  software  to  the  system.  Overall,  these  changes 
make  it  more  difficult  to  transport  the  developed  Ada  software 
to  another  target  machine  or  to  use  a  different  set  of  Ada 
tools  (off-the-shelf). 

10.  3.  5  Complexity 

The  extensive  system  optimization  that  is  performed  during  the 
development  of  Ada  systems  can  increase  the  overall  complexity 
of  the  system.  This  is  due  in  part  to  the  pat'ching  that  must 
be  done  to  the  original  design  to  implement  changes, 
particularly  if  the  system  is  not  designed  in  a  modular  fashion 
to  accommodate  such  changes.  The  requirement  for  special- 
purpose  heirdware  and  software  to  perform  the  optimization  also 
contributes  to  the  increase  in  system  complexity. 

10.  8.  6  Reusability 

The  extensive  system  optimization  that  is  performed  during  the 
development  of  Ada  systems  can  reduce  the  reusability  of  the 
system  and  applications  software.  This  is  because  a  number  of 
the  changes  that  are  made  to  support  the  optimization  efforts 
are  project-specific.  These  changes  are  implemented  by 
modifying  the  applications  and  system  software  to  take 
advantage  of  design  and  implementation  details  that  are 
specific  to  the  application  being  developed  and  to  any  special- 
purpose  hardware  and  software  that  are  used  in  the  application. 
The  overall  effect  is  to  reduce  the  reusability  of  the 
applications  and  system  software. 
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10.  8.  7  Development  Environment 

The  extensive  optimiration  performed  during  the  development  of 
Ada  systems  can  affect  the  applications  development 
environment.  This  occurs  when  the  proposed  optimization 
approach  requires  the  use  of  special-purpose  hardware  or 
additional  system/support  software.  Drastic  changes  to  the 
development  environment  can  have  a  major  impact  on  the  overall 
system  performance  and  characteristics  and  can  also  adversely 
impact  the  system  development  schedule. 

10.  3.  8  Non-Ada  Software 

To  implement  the  extensive  optimization  that  is  performed 
during  the  development  of  Ada  systems,  the  use  of  non-Ada 
software  may  be  required.  This  non-Ada  software  is  generally 
used  to  improve  system  performance  (sizing  and  timing)  or  to 
implement  machine-dependent  functions  (low-level  hardware 
interface  es).  However,  the  use  of  non- Ad  a  software, 
particularly  assembly  language,  tends  to  reduce  the  overall 
maintainability  of  the  system,  due  to  the  fact  that  most  non- 
Ada  languages  cannot  provide  the  readability, 
understandability ,  and  power  of  Ada. 

10.  3.  9  Vendor  Interface 

in  the  current  Ada  development  environment,  a  large  amount  of 
the  system  optimization  that  is  performed  involves 
modifications  to  the  Ada  compiler  and  RSL.  .Thus,  it  is 
critical  that  a  working  interface  be  established  between  the 
applications  developer  and  the  compiler  vendor.  The  compiler 
vendor  should  provide  information  to  the  applications  developer 
concerning  the  operation  and  performance  of  the  Ada  tools  that 
are  supplied  (consulting  support)  and  should  also  implement  any 
required  changes  to  these  tools. 

10.  3.  10  con^iler 

In  the  current  Ada  development  environment,  a  large  number  of 
the  changes  that  are  implemented  during  optimization  are  made 
to  the  compiler  and  RSL.  The  complexity  of  the  compiler  makes 
it  essential  that  extensive  regression  testing  is  performed 
while  implementing  these  changes.  It  is  easily  conceivable 
that  implementing  a  change  to  one  portion  of  the  compiler  could 
impact  other  sections  of  the  compiler,  thus  possibly  reducing 
the  overall  correctness  and  reliability  of  the  compiler. 
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10.  8. 11  Preliaiinary  Design 

During  the  Preliminary  Design  Phase,  the  Initial  optimization 
methods  that  are  necessary  to  meet  system  requirements  should 
be  identified.  This  optimization  can  result  in  changes  to  the 
design  of  the  applications  program  and  also  to  the  design  of 
the  Ada  software  tools  (compiler,  etc.).  Those,  optimization 
requirements  that  are  not  identified  in  this  phase  must  then  be 
identified  in  later  phases,  where  a  larger  amount  of  effort  is 
required  to  rework  the  design. 

10.  8. 12  Detail  Design 

4 

During  the  Detailed  Design  Phase,  those  optimization 
requirements  that  were  not  identified  during  the  Preliminary 
Design  Phase  must  be  addressed.  The  optimization  efforts  may 
involve  changes  to  the  applications  programs  and  the  Ada  system 
software  tools  (compiler,  etc.).  Any  optimization  requirements 
that  are  not  addressed  in  this  phase  must  be  addressed  in  later 
phases,  where  the  effort  required  to  rework  the  design  is  much 
more  extensive.  Also,  any  requirements  for  special-purpose 
hardware  and  software  should  be  identified  in  ^is  phase  and 
incorporated  into  the  overall  system  design. 

10.  3.  13  CSC  Test 

During  the  CSC  Test  phase,  the  additional  system  complexity 
that  results  from  the  extensive  Ada  system  optimization 
increases  the  effort  required  to  test  and  verify  CSC 
performance  and  operation.  Also,  any  additional  system 
optimization  tasks  that  are  identified  in  this  phase  will 
require  more  effort  to  implement  because  they  were  found  so 
late  in  the  system  development  cycle. 

10.  8.  14  CSCI  Test 

During  the  CSCZ  Test  phase,  the  additional  system  complexity 
which  results  from  the  extensive  Ada  system  optimization 
increases  the  effort  required  to  test  and  verify  CSCZ  operation 
and  performance.  Also,  any  additional  system  optimization 
tasks  that  are  Identified  in  this  phase  will  require  more 
effort  to  implement  because  they  were  found  so  late  in  the 
system  development  cycle. 

10.  8. 15  Personnel  Resources 

To  perform  the  extensive  optimization  that  is  required  to 
develop  Ada  systems,  a  larger  number  of  senior  engineers  are 
required.  These  engineers  must  have  experience  in  the  design 
and  implementation  of  Ada  systems  and  must  have  some  knowledge 
of  the  operation  and  performance  of  Ada  system  tools.  These 
personnel  requirements  should  be  supplemented  by  obtaining 
consulting  support  from  the  compiler  vendor. 
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10.  8. 16  Facilities 

The  extensive  optimization  that  is  required  to  develop  Ada 
systems  can  result  in  a  requirement  for  additional  development 
and  test  equipment  and  facilities.  The  additional  equipment 
could  include  special-purpose  hardware,  system  software,  and 
support  tools.  The  additional  facilities  could  include 
sophisticated  emulation  and  debugging  systems  to  address  the 
increased  complexity  of  the  applications  programs. 

10.  8.  17  Cost 

The  extensive  optimization  performed  during  the  development  of 
Ada  systems  can  add  significantly  to  the  system  development 
cost.  The  development  costs  can  increase  significantly  if  the 
proposed  system  changes  result  in  extensive  rework  to  the 
system  design  and  implementation.  The  development  cost  can  be 
further  increased  if  the  optimization  requirements  are  not 
identified  until  late  in  the  system  development  cycle,  since 
this  increases  the  amount  of  rework  that  is  required. 

10.  8.  1 8  Schedule 

The  extensive  optimization  that  is  performed  during  the 
development  of  Ada  systems  can  have  a  significant  impact  on  the 
system  development  schedule.  The  development  schedule  can  be 
lengthened  due  to  the  extensive  amount  of  effort  required  to 
rework  the  system  design  and  implementation.  The  development 
schedule  can  be  further  impacted  if  the  optimization 
requirements  are  not  identified  until  late  in  the  system 
development  cycle. 

10.  8.  19  Estimation 

To  ensure  that  the  proposed  system  development  cost  and 
schedule  are  as  c omple  te  and  accur a  te  as  possible,  the 
estimated  effort  required  to  perform  Ada  system  optimization 
should  be  included  in  the  overall  project  estimates.  This  data 
can  be  estimated  using  historical  data,  if  it  is  available,  or 
by  using  a  reasonable  estimate  for  the  particular  type  of  Ada 
application  being  developed,  based  on  Ada  software  cost 
estimation  models.  However,  it  should  be  noted  that, 
currently,  very  little  historical  data  exists  for  Ada  projects 
and  very  few  Ada  cost  estimation  models  exist  which  have  been 
proven  to  be  accurate. 


IB  46 


REAL-TIME  AOA  PROBLEM  STUDY 


10/  9/  87 


10.  9  INAOBQOATE  DEB066ING  CAPABILITIES  PROVIDED  BY  CORRENT 
DEBOGGEBS 

Poor  debugging  tools  do  not  give  the  engineer  adequate  control 
and  visibility  of  the  program  at  run-tine.  This  will  directly 
affect  the  verifiability  of  the  program  and  the  system. 

10.  9.  1  Debugger 

The  debugger  plays  a  major  role  in  the  finalization  of  a 
software  development  effort.  An  inadequate  debugger  can  cause 
long  delays  in  the  finalization  process.  Thus,  schedules  are 
slipped  and  cost  impacts  are  incurred.  Because  the  designer 
will  now  have  to  debug  a  system  that  contains  code  not 
developed  by  himself,  the  problem  of  an  inadequate  debugger  is 
compounded.  Such  is  the  case  with  Ada  debuggers  that  do  not 
provide  the  necessary  control  and  visibility  to  efficiently 
debug  an  Ada  program.  Hence,  the  designer  may  be  forced  to 
contract  the  vendor  of  the  run-time  support  library  to  help 
debug  his  system. 
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10.  10  ADA  EXCEPTION  HANDLING 

The  whole  idea  of  handling  unexpected  errors  at  run-time  is  a 
very  good  concept.  But  having  developed  and  debugged  some  Ada 
programs,  one  begins  to  sense  there  is  a  problem  with  the 
handling  of  exceptions.  The  problem  has  to  do  with  the  manner 
in  which  an  exception  is  reported  to  the  engineer  and  the  Lack 
of  information  that  is  conveyed.  This  is  particularly  true  when 
the  exception  that  is  raised  is  a  non-user-defined  exception. 
Further,  if  the  application  program  does  not  require  the 
inclusion  of  TEXT_IO,  and  many  will  not  because  of  its  large 
size,  or  no  capability  to  display  text  messages  exists  in  the 
run-time  program,  the  problem  can  be  compounded.  This  is 
because  it  is  now  possible  for  an  exception  to  be  raised  and 
Che  engineer  not  know  of  its  existence  until  it  manifests 
itself  as  a  failed  function  much  later.  Now  the  engineer  must 
search  for  the  source  of  the  exception  and  then  determine  why 
the  exception  was  raised.  Depending  on  the  debugging  tools 
available  to  the  engineer  and  how  far  the  manifestation  of  the 
problem  is  from  the  real  problem,  the  determination  of  the 
problem  can  be  long,  frustrating  and  costly. 

10.10.1  Verifiability 

The  inability  of  today's  run-time  support  code  to  generate 
adequate  trace-back  information  when  exceptions  occur  will 
directly  affect  the  verifiability  of  Ada  programs.  Without 
verification  of  proper  execution,  bugs  can  remain  in  progreuns 
and  cause  future  problems  in  the  application  system. 
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10.  11  IMPACT  OF  EXTENSIVE  USE  OF  GENERICS 

The  use  of  Ada  generics  is  regarded  as  a  najor  step  towards  the 
development  of  reusable  Ada  programs.  However,  in  the  current 
Ada  environment,  extensive  use  of  Ada  generics  can  adversely 
impact  the  performance  of  Ada  systems  and  the  productivity  of 
Ada  development  efforts.  The  extensive  use  of  generics  can 
result  in  a  significant  increase  in  sys.tem  memory  requirements. 
This  is  due  to  the  general  inefficiency  of  code  that  must  be 
shared  by  a  variety  of  programs,  the  additional  code  that  must 
be  required  to  implement  conditional  processing  within  the 
shared  code,  and  the  additional  processing  required  to 
implement  the  use  of  the  actual  parameters  within  the  generic 
instantiation. 

There  are  also  impacts  on  productivity*.  Each  time  a  generic 
program  is  changed,  all  programs  which  contain  an  ' nstantiation 
of  the  generic  must  be  recompiled.  Also,  the  generics 
instantiations  are  essentially  compiled  as  in-line  code,  which 
increarses  overall  compile  time. 

10.  11. 1  Efficiency 

The  extensive  use  of  generics  can  have  an  adverse  impact  on 
system  efficiency.  One  reason  for  this  adverse  impact  is  that 
code  designed  to  be  used  (shared)  by  number  of  different 
programs  is  generally  written  less  efficiently  than  code  that 
is  only  to  be  used  for  one  specific  purpose.  The  algorithms 
for  shared  code  are  usually  written  in  a  more  general 
(flexible)  fashion  and  the  shared  code  usually  involves  some 
amount  of  conditional  processing,  which  also  reduces 
efficiency. 

Because  of  the  way  in  which  Ada  implements  generics,  a 
substantial  amount  of  code  which  supports  the  actual  parameters 
for  each  generic  instantiation  is  included  in  the  memory 
requirements  for  generics.  Also,  in  some  implementations  of 
the  Ada  compiler,  generics  are,  in  effect,  compiled  as  in-line 
code.  This  can  greatly  increase  the  system  memory 
requirements. 

10. 11.  2  Benchmaric 

To  obtain  an  estimate  of  the  impact  on  system  memory 
requirements  on  the  extensive  use  of  generics,  it  is 

important  to  benchmark  the  performance  of  the  compiler  in 
generating  the  generic  instantations.  This  information  is 

useful  in  assessing  the  overall  system  resource  requirements. 
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10.  11.  3  Optiaization 

The  extensive  use  of  generics  could  cause  a  significant 
increase  in  system  memory  requirements.  Minimizing  the  impact 
of  these  increased  memory  requirements  could  require  system 
optimization.  This  optimization  could  include  modifying  the 
processing  performed  by  the  generic  to  require  less  memory  or 
modifying  the  compiler  to  reduce  the  memory  requirements  for 
generic  instantiations. 

10.  11.  4  System  Sizing 

The  extensive  use  of  generics  could  cause  a  significant 
increase  in  the  overall  system  memory  requirements.  This 
impact  must  be  considered  when  performing  system  sizing 
estimates. 

10.  11.  5  Prototype 

The  extensive  use  of  generics  can  cause  significant  increases 
in  the  system  memory  requirements.  To  obtain  an  assessment  of 
the  actual  system  impact  and  to  evaluate  the  potential  memory 
savings  due  to  the  proposed  system  optimization  techniques,  a 
prototype  of  the  system  should  be  built.  The  information 
obtained  from  the  prototyping  effort  provides  valuable  input  to 
the  system  design. 

10.  11.  6  Cost 

The  increased  system  memory  requirements  that  result  from 
extensive  use  of  generics  and  the  effort  required  to  perform 
system  optimization  can  increase  the  overall  system  development 
cost.  Overall  project  productivity  is  decreased  because  each 
time  a  generic  is  modified  and  recompiled,  all  programs  which 
instantiate  that  generic  must  be  recompiled.  Also,  the 
generics  are  often  compiled  as  if  they  were  in-line  code,  which 
increases  overall  system  compilation  time. 
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10.  12  INABILITY  TO  PERFORM  INDEPENDENTLY  OF  THE  RSL 

One  of  the  conunon  requirements  for  the  embedded  system  is  the 
requirement  to  perform  Buil'w  In  Test  (BIT).  BIT  is  the  ability 
of  the  embedded  system  to  perform  a  self-test  without  external 
equipment  and  indicate  if  the  system  is  good  or  bad.  BIT  is 
usually  performed  by  some  combination  of  hardware  emd  software. 
One  of  the  key  functions  in  performing  a  self-test  is  the 
setting  of  the  system  to  a  known  state.  A  good  example  of  this 
would  be  the  initialization  of  RAM  (random  access  memory).  When 
an  embedded  system  is  first  powered  up,  the  state  of  RAM  is 
unknown.  Therefore,  one  of  the  functions  of  BIT  is  to  set  RAM 
to  a  known  state  and  then  verify  it.  The  problem  occurs  when 
the  application  is  implemented  in  the  Ada  language.  The  run¬ 
time  support  code  is  designed  to  take  control  of  the  system  at 
power-up  and  perform  system  elaboration.  When  elaboration  is 
completed  all  task  stacks  and  variables  have  been  allocated. 
But  the  state  of  memory  (RAM)  is  still  indeterminate.  If  BIT 
were  to  run  after  elaboration  it  would  destroy  the  state  set  up 
by  the'  RSL.  Therefore,  BIT  must  execute  before  the  RSL.  Today, 
one  must  modify  the  run-time  support  code  to  perform  this  type 
of  function,  and  to  do  so  can  be  very  costly  auid  time  consuming 
because  you  are  modifying  someone  else's  code. 

10.12.1  Reliability 

The  inability  to  perform  BIT  befre  the  RSL  configures  processor 
memory  means  that  much  of  RAM  is  untestable.  This  would  have  a 
severe  impact  on  system  reliability  because  a  RAM  failure  could 
go  undetected  for  some  time,  causing  erroneous  operation  of  the 
system.  Since  this  unacceptable,  some  other  scheme  is 
necessary  as  a  work-around,  such  as  RAM  bank  seitching  or  an 
assembly  language  routine  that  runs  before  the  RSL  takes  over. 
Bank  switching  is  usually  not  an  usually  not  an  option  due  to 
the  system  penalties  when  additional  computer  resources  are 
used. 

10.  12.  2  Vendor  Interface 

The  use  of  w  assembly  language  routine  to  perform  BIT  before 
the  RSL  configures  processor  memory  can  require  extensive 
vendor  interface.  This  is  because  many  RSLs  are  currently 
unable  to  surrender  control  grcefully,  as  BIT  requires.  Where 
the  ability  to  seize  control  is  designed  into  the  RSL  this 
aspect  of  the  problem  goes  away. 

10.  12.  3  IMPORTER 

The  use  of  an  assembly  language  routine  to  perform  BIT  before 
the  RSL  configures  processor  memory  requires  some  provision  for 
importing  code  written  in  a  language  other  than  Ada.  This 
capability  is  usually  present  in  Ada  compillers  now  on  the 
market  so  this  is  rarely  a  problem. 
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10.  12.  4  Preliminary  Design 

The  use  of  an  assembly  language  routine  to  perform  BIT  before 
the  RSL  configures  processor  memory  impacts  the  Preliminary 
Design  phase  of  the  development  cycle.  During  this  phase  the 
compiler  must  be  selected,  and  the  requirements  for  an  importer 
[refer  to  Importer  discussion  for  this  problem]  and  for  vendor 
interfce  to  assuure  a  way  to  seise  control  from  the  RSL  [refer 
to  Vendor  Interface  discussion  for  this  problem]  should  be  a 
big  consideration  in  its  selection.  Failure  to  address  these 
needs  will  impact  subsequent  design  phases  very  severely. 
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10.13  LACK  OP  A  OISTRIBOTED  RON-TIME  SOPPORT  LIBRART  (RSL). 

The  term  "concurrent  processing*  is  often  mentioned  in  the  same 
breath  as  Ada.  This  is  because  the  Ada  is  designed  with 
concurrent  processing  as  a  goal.  This  goal  is  met  by  creation 
of  tasks.  However,  many  of  today's  implementations  of  the  Ada 
Language  Reference  Manual  (LRM)  are  not  capable  of  true 
parallel  (concurrent)  processing,  ^is  can  be  attributed  to  the 
lack  of  RSLs  that  are  designed  to  be  distributed  across 
multiple  processors.  Another  reason  may  be  the  LRM  itself, 
since  it  does  not  address  the  requirements  for  distributed  Ada 
processing.  Many  of  today's  embedded  system  applications  have 
requirements  that  warrant  the  design  of  systems  capable  of  true 
parallel  processing.  Where  parallel  processing  is  required,  the 
technique  that  is  often  implemented  is  distributed  processing. 
Distributed  processing  occurs  when  computer  processes  are 
distributed  across  multiple  computer  processing  units  (CPU)  to 
achieve  true  parallel  processing.  Today,  an  embedded  system 
with  multiple  processors,  implemented  in  the  Ada  language,  must 
develop  Ada  programs  for  each  CPO  in  the  systenu  Thus,  the 
system  incurs  the  cost  of  additional  memory,  timing,  and 
hardware  to  accommodate  an  RSL  for  each  processor. 

10.  13. 1  Efficiency 

Lack  of  a  distributed  RSL  hurts  memory  efficiency  by  forcing  a 
separate  copy  of  the  RSL  in  each  processor  which  is  using  Ada 
instructions.  Strong  coupling  to  a  central  memory  bank 
containing  the  RSL  conflict  arbitration  schemes  not  available 
in  current  Ada  compilers. 

10.  13.  2  Integrity 

Lack  of  a  distributed  RSL  hurts  software  integrity  because 
processors,  being  loosely  coupled,  cannot  be  built  up  in  a 
hierarchically  secure  manner.  The  most  secure  systems 
("trusted"  systems)  have  an  almost  impenetrable  single  core, 
which  is  impossible  in  a  distributed  Ada  system  today  without 
extensive  modification  to  the  RSL. 

10.  13.  3  System  Sising 

Lack  of  a  distributed  RSL  increases  system  sizing  because 
multiple  copies  of  the  RSL  are  required.  Even  in  a  modest 
system  of  three  or  four  processors  this  can  add  on  the  order  of 
100  kilobytes  to  the  memory  requirement  (depending  on  the 
compiler  selected).  For  complex  systems,  such  as  modern 
avionics  with  over  a  hundred  processors,  this  penlty  can  be 
severe  enough  to  redesign  the  RSL  to  eliminate  the  multiple 
copies. 
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10.14  DIFEZCOLTT  IN  PERFORMING  SECURE  PROCESSING  FOR  ADA 
SYSTEMS 

Due  to  the  current  unavailability  of  a  secure  Ada  operating 
system  and  the  excessive  overhead  associated  with  the  use  of  a 
secure  Ada  kernel  to  restrict  system  memory  accesses,  it  is 
currently  difficult  to  build  a  secure  processing  application  in 
Ada. 

The  Ada  language  allows  the  applications  programmer  to  perform 
run-time,  and  system  level  operations  which  increase  the 
difficulty  involved  in  protecting  classified  programs  and  data 
within  the  system.  These  operations  include  the  creation, 
access,  and  destruction  of  objects  at  run-time,  the  use  of 
address  specif ications  to  access  particular  memory  locations; 
and' the  writing  and  execution  of  in-line  assembly  Language 
programs. 

Also,  the  RSL  code  is  not  on ly ' res iden t  in  the  target 
en vir on^ient,  but  runs  in  conjunction  with  the  applications 
programs.  Thus,  to  fully  verify  the  security  of  an  Ada 
system,  the  RSL  code  must  be  evaluated  and  certified  as  part 
of  the  system  certification  effort.  This  is  difficult  because 
most  Ada  applications  programmers  have  little  knowledge 
concerning  the  operation  of  the  RSL. 

10. 14. 1  Integrity 

One  of  the  major  problems  in  developing  Ada  systems  to  perform 
secure  processing  is  to  maintain  system  integrity  (programs  and 
data).  Ada  is  a  very  powerful  language  which  allows  an 
applications  programmer  to  perform  low-level  activities  such  as 
creating,  accessing,  and  destroying  objects  at  run-time;  using 
address  specifications  to  access  specific  memory  locations;  and 
writing  and  executing  in-line  assembly  language  prograuns.  The 
Ada  run-time  environment  also  contains  the  RSL  which  operates 
in  conjunction  with  the  applications  programs  and  accesses  the 
system  data  in  memory. 

Capabilities  such  as  these  make  it  much  more  difficult  to 
ensure  the  integrity  of  system  programs  and  data  since  they  can 
be  performed  at  run-time  by  the  applications  programmer  or  by 
the  system  software  (RSL).  Currently,  there  are  no  secure 
operating  systems  available  for  use  in  Ada  systems,  and  the 
overhead  involved  with  implementing  a  secure  kernel  is 
prohibitive  for  most  Ada  applications.  Thus,  these  security 
issues  are  generally  addressed  at  the  program  level  and  by  the 
use  of  special-purpose  hardware  which  provides  the  required 
protection. 
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10. 14.  2  Security 

For  Ada  systems  in  which  secure  processing  must  be  performed, 
the  difficulty  required  to  construct  a  secure  Ada  environment 
can  be  a  major  source  of  problems.  Currently,  there  are  no 
secure  operating  systems  for  use  in  the  development  of  secure 
Ada  applications,  and  the  overhead  associated  with  the  use  of  a 
secure  kernel  is  generally  considered  too  prohibitive  for 
current  Ada  applications. 

The  security  level  of  the  Ada  applications  programs  can  be 
monitored  reasonably  well  by  reviewing  the  applications 
programs  at  both  the  source  and  object  code  levels.  However, 
this  task  is  made  more  difficult  by  the  availability  of  certain 
Ada  features  that  can  be  used  by  the  Ada  applications  developer 
at  run-time.  These  features  include  creating,  accessing,  and 
deleting  objects;  using  address  specifications  to  access 
specific  memory  locations;  and  writing  and  executing  in-line 
assembly  code. 

Another  security  problem  is  created  because  the  RSL  progreuns 
are  resident  in  memory  and  operate  in  conjunction  with  the 
applications  programs.  To  properly  ensure  system  security,  the 
RSL  programs  must  also  be  verified  and  certified  to  meet  system 
security  requirements. 

10.  14.  3  Cooplezity 

Currently,  there  is  a  lack  of  secure  operating  systems  for  Ada 
applications  and  the  overhead  associated  with  building  a  secure 
kernel  is  considered  to  be  prohibitive  for  most  Ada 
applications.  Thus,  Ada  applications  developers  must  generally 
use  special-purpose  hardware  and  software  to  implement  the 
security  mechanisms  required  to  protect  the  system  programs  and 
data.  However,  this  special-purpose  hardware  and  software  can 
increase  system  complexity  through  the  addition  of 
sophisticated  wd  complex  hardware  and  software  interfaces. 

10.14.4  Risk 

The  security  risks  associated  with  developing  a  secure  Ada 
system  in-  involve  two  major  areas. 

The  first  area  is  providing  protection  to  offset  the  powerful 
run-time  memory  access  and  control  capabilities  provided  to  the 
applications  programmer  by  the  RSL.  Standards  and  procedures 
must  be  established  to  monitor  the  usage  of  these  functions. 
If  this  is  not  done  properly,  it  is  possible  that  the  system 
might  not  receive  certification. 

The  second  area  is  to  verify  and  certify  the  RSL  software  which 
resides  in  the  target  environment  and  operates  in  conjunction 
with  the  applications  software.  This  is  risky  because  it  must 
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be  done  in  the  context  of  th-e  application  environment 
(hardware,  software,  optimization)  to  achieve  system 
certification,  and  any  problems  that  are  found  could  require  a 
significant  effort  to  correct  (special-purpose  hardwaure  auid 
software,  system  redesign). 

10.14.5  Development  Envlronsient 

Currently,  due  to  the  lack  of  a  secure  Ada  operating  system  and 
the  overhead  associated  with  developing  a  secure  kernel, 
security  requirements  are  generally  implemented  through  the  use 
of  special-purpose  hardware  and  software.  The  addition  of  this 
special-purpose  hardware  and  software  and  the  overhead 
associated  with  performing  the  security  can  have  a  significant 
impact  on  the  development  environment.  It  may  require  the 
redesign  of  system  interfaces  and  optimization  to  provide 
system  performance  enhancements.  Also,  the  security 
requirements  and  the  proposed  method  of  implementation  are  a 
major  factor  in  the  choice  of  system  hardware,  software,  and 
support  tools. 

¥ 

10.  14.  6  Vendor  Interface 

Due  to  the  lack  of  a  secure  Ada  operating  system  and  the 
overhead  associated  with  developing  a  secure  kernel,  a  number 
of  the  system  modifications  that  must  be  made  to  meet  security 
requirements  involve  changes  to  the  system  and  support  software 
(compiler,  RSL,  debugger,  etc..).  To  implement  these  changes, 
the  applications  developers  will  require  extensive  support  from 
the  cosqsiler  developers.  Thus,  a  fairly  flexible  interface 
must  be  established  between  the  compiler  vendors  and  the  Ada 
applications  developers. 

10.  14.  7  Prototype 

To  ensure  that  the  security  measures  required  to  support  the 
development  and  operation  of  an  Ada  system  have  been  properly 
designed  and  implemented,  a  prototype  should  be  built  and  used 
to  verify  their  correctness.  The  prototype  will  also  provide 
information  concerning  the  impact  on  system  performance  due  to 
the  overhead  associated  with  performing  the  required  system 
security  functions. 

10. 14.  8  Compiler 

Due  to  the  lack  of  a  secure  Ada  operating  system  and  the 
excessive  overhead  associated  with  a  secure  kernel,  a  number  of 
the  system  changes  chat  are  implemented  to  meet  security 
requirements  involve  modifications  to  the  compiler  and  RSL. 
These  modifications  might  include  adding  software  to  the  RSL  to 
provide  an  interface  to  any  special-purpose  security  hardware 
and  software  in  the  system. 

It  is  important  to  assess  the  impact  of  these  changes  on  other 
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parts  of  the  compiler  and  RSL  and  on  the  applications  programs. 
It  should  be  noted  that  if  modifications  such  as  these  are  made 
to  the  compiler  and  RSL  after  they  have  been  certified,  the 
software  must  then  be  recertified  before  it  can  become  part  of 
the  system. 

10.14.9  Software  Requirements  Analysis 

During  the  Software  Requirements  Analysis  Phase,  the  system 
security  needs  must  be  reviewed  to  determine  which  ones  can  be 
achieved  based  on  the  security  capabilities  of  the  Ada 
development  environment.  Those  security  requirements  which 
cannot  be  met  (due  to  the  lack  of  a  secure  Ada  operating  system 
or  to  the  prohibitive  overhead  associated  with  a  secure  kernel) 
must  be  identified  for  resolution  later  on  in  the  system 
development  cycle.  Failure  to  identify  security  issues  early 
on  could  result  in  extensive  system  design  rework  in  later 
development  phases. 

10.14.10  Preliminary  Design 

In  the  Preliminary  Design  Phase,  those  security  issues  that 
were  identified  in  the  Software  Requirements  Analysis  Phase 
must  be  addressed.  Solutions  must  be  designed  and  incorporated 
into  the  overall  system  design.  If  the  solutions  require 
special-purpose  hardware/software  or  changes  to  the  system 
software  (compiler,  RSL,  etc.),  then  these  issues  should  be 
initially  addressed  during  this  phase.  If  these  issues  are 
ignored  until  later  development  phases,  the  amount  of  effort 
required  to  rework  the  system  design  increases  significantly. 

10.  14.  11  Personnel  Resources 

To  develop  a  -secure  Ada  application,  the  required  personnel 
qualifications  are  much  more  intensive  than  for  a  non-secure 
application.  The  project  personnel  must  be  experienced  in  the 
design  and  development  of  secure  systems,  including  the  use  of 
special-purpose  hardware  and  software  to  implement  security 
requirements.  They  must  also  be  familiar  with  the  security 
limitations  placed  on  the  system  based  on  the  choice  of  an  Ada 
compiler  and  RSL  for  a  particular  application.  This  knowledge 
should  be  supplemented  by  technical  support  from  the  compiler 
vendor. 

Personnel  with  this  type  of  background  ace  bard  to  find. 
However,  if  these  people  cannot  be  found,  the  project  runs  the 
risk  of  not  being  completely  responsive  to  the  system  security 
requirements,  thus  making  it  difficult  to  obtain  system 
certification. 

10.  14.  12  Cost 

The  workarounds  that  are  required  due  to  the  lack  of  a  secure 
Ada  operating  system  and  the  excessive  overhead  associated  with 
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a  secure  kernel  can  significantly  increase  the  development  cost 
for  a  secure  Ada  application.  These  workarounds  can  include 
modifications  to  the  Ada  system  software  (compiler,  RSL,  etc.  ) 
and  the  addition  of  special-purpose  hardware  and  software  to 
Implement  system  security  requirements. 


'3  S8 


REAL-TIME  ADA  PROBLEM  STOOY 


10/9/87 


10.  15  DZVSRSITX  IN  IMPLEMENTATION  OF  APSE'S 

The  tasic  of  developing  Ada  softw2u:e  for  computers  integral  to 
weapon  systems  is  a  complex  one,  and  would  be  impossible 
without  good  support  tools.  The  set  of  these  tools  to  be  used 
with  an  Ada  compiler  is  called  an  Ada  Program  Support 
Environment  (APSE),  and  the  APSE  has  been  the  subject  of  much 
study  since  the  Ada  language  was  specified. 

One  of  the  problems  recognized  very  early  by  both  the  Army 
Communications  and  Electronics  Command  (CECOM)  and  by  the  Air 
Force  was  the  need  for  standardized  and  portable  APSEs.  ^e 
Air  Force  effort  was  lost  in  a  funding  problem  soon  after  its 
inception,  and  the  CECOM  effort,  which  resulted  in  the  Ada 
Language  System  (ALS) ,  was  terminated  and  made  public  domain. 
Sonicraft,  which  contracted  Softech  to  retarget  the  ALS  to  the 
Intel  8086,  tried  the  ALS  and  found  tool  performance  below  the 
range  of  usability. 

This  left  the  situation  where  each  compiler  vendor  has  mariceted 
its  own  version  of  an  APSE,  with  each  requiring  training  both 
for  users  ^und  for  the  host  computer  support  engineers.  This,  in 
turn,  has  made  it  far  more  difficult  to  transition  from  one 
compiler  to  another  during  a  project,  a  necessity  all  too  often 
brought  about  by  other  Ada  problems  [Problem  #17  for  example]. 

The  extent  of  this  problem  depends  upon  the  complexity  of  the 
APSE  that  you  now  have  and  the  one  you  are  considering 
acquiring.  If  one  of  the  APSEs  is  the  ALS,  the  problem  is  very 
severe.  Sonicraft  jad  to  send  three  VAX  system  support 
engineers  to  a  two  week  course  just  to  learn  to  install  and 
configure  the  tools  in  the  ALS.  Users  also  needed  training, 
which  was  given  by  these  three  engineers.  Then,  because  of  the 
extreme  slowness  of  ALS  operations  (about  a  tenth  as  fast  as 
comparable  operations  under  the  DEC  VMS  operating  system) ,  a 
major  effort  was  required  to  try  to  "tweak*  the  ALS  and  the 
underlying  VMS  parameters  to  effect  a  speedup.  This  big 
investment  in  time  and  money  was  sacrificed  when  Sonicraft 
abandoned  the  ALS. 

Col.  Wm.  Whitaker  (Ret),  commenting  on  a  WIS  report  at  the 
Washington  Ada  Symposium,  stated  that  most  programmers  make  do 
with  a  very  minimal  support  environment,  and  that  many  of  the 
exotic  tools  described  in  the  literature  either  do  not  work  or 
are  not  widely  used  (or  both).  One  study  [Ref]  defines  the 
minimal  tool  set  needed  as  a  screen  editor  and  an  interactive 
debugger.  You  are  indeed  fortunate  if  your  APSE  contains  a  good 
source-level  interactive  debugger  [Problem  #9],  but  many  APSEs 
contain  tool  sets  which  are  quite  complex,  requiring  training 
for  all  project  designers  and  host  support  people. 

[Ref]  S.  J.  Hanson  and  R.  R.  Rosinski,  "‘Programmer  Perceptions  of 
Productivity  and  Programming  Tools",  Communications  of  the  ACM, 
Feb  35 


S  59 


REAL-TIME  ADA  PROBLEM  STOOY 


10/  9/  87 


10. 15. 1  Reliability 

The  diversity  in  implementation  of  APSEs  can  hurt  program 
reliability  during  the  transition  from  one  APSE  to  another  if 
it  occurs  in  the  middle  or  near  the  end  of  a  project.  By  this 
time  the  application  has  grown  complex  enough  that  programmers 
can  become  confused,  and  their  unfamiliarity  with  the  new  APSE 
offers  just  such  an  occasion.  The  more  complex  the  new  APSE  is, 
and  the  harder  it  is  to  learn,  the  more  severe  will  this 
problem  become.  A  confused  programmer  is  more  apt  to  insert  a 
"bug",  or  program  fault,  which  of  course  will  by  definition 
reduce  program  reliability  until  it  is  found  and  corrected. 

10. 15.  2  Maintenance 

The  diversity  in  implementation  of  APSEs  affects  the  program 
maintenance  if  a  switch  in  APSEs  occurs  right  before  delivery. 
This  is  not  as  far-fetched  as  it  may  seem,  because  if  system 
performance  meets  specifications  only  marginally,  as  it  did  for 
the  Sonicraft  MEECN  project,  an  investment  in  an  alternative 
compiler  may  be  made  in  parallel  with  the  original  one  (as 
Sonicraft  has  done  more  than  once).  If  the  alternative  proves 
to  be  better,  a  switch  could  be  made. 

The  later  in  the  program  this  switch  is  made,  the  more  likely 
it  is  that  the  customer  has  made  some  commitments  toward  system 
maintenance  that  will  have  to  be  changed.  The  system 
maintenance  concept  is  a  Critical  Design  Review  (CDR)  topic  on 
most  programs,  so  at  least  some  cost  is  needed  to  present  a  new 
maintenance  concept  to  CDR  attendees. 

10. 15.  3  Portability 

Diversity  in  implementation  of  APSEs  can  hurt  portability  in 
several  ways.  First,  the  APSE  itself  is  probably  optimized  for 
a  particular  host,  so  extensive  rework  would  be  required  to 
rehost  it. 

Second,  Sonicraft  found  it  necessary  to  tailor  the  application 
code  for  both  the  ALS  and  the  second  compiler  we  used,  the 
Softech  Ada  Intel  Toolset  (AIT).  Some  of  these  work-arounds, 
although  correct  Ada  code,  may  not  work  on  a  third  compiler, 
and/or  the  third  compiler  may  need  tailoring  of  its  own. 

Third,  although  the  compiler  is  by  far  the  most  complex  tool  in 
the  current  APSEs,  some  of  the  other  tools  may  not  be  portable, 
even  if  the  host  computer  is  unchanged,  because  they  are 
strongly  tied  into  the  compiler  in  some  way. 
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10. 15. 4  Training 

Diversity  in  implementation  of  APSEs  requires  retraining  of 
application  developers,  host  computer  support  personnel,  and 
engineers  from  other  disciplines  (Systems,  Test,  Quality,  etc.) 
who  need  visibility  into  the  application  code  each  time  the 
project  is  forced  to  change  APSES. 


10.  15.  5  Tool  Ose 

Diversity  in  the  implementation  of  APSEs  tends  to  discourage 
tool  usage,  at  least  for  those  tools  not  minimally  essential  to 
get  visibility  into  the  application  code  and  to  be  able  to 
manipulate  it  relatively  easily.  Sonicraft,  having  invested 
heavily  in  training  to  use  the  wide  range  of  tools  in  the  ALS, 
only  to  see  that  investment  lost  when  the  ALS  had  to  be 
dropped,  will  not  soon  make  another  large  investment. 

10.  15. £  Development  Environment 

Diversity  in  implementation  of  APSEs  affects  the  development 
environment  because  the  user  interface  to  the  APSE  is  usually 
very  different  when  you  go  to  a  new  APSE.  Although  the  hardware 
in  the  environment  does  not  have  to  change,  it  is  nonetheless 
true  that  the  APSE  is  the  controlling  mechanism  of  many  of  the 
services  that  the  hardware  performs. 

10. 15.  7  Vendor  Interface 

The  diversity  in  implementation  of  APSEs  affects  the  vendor 
interface  because  the  investment  in  training  (especially  for  a 
very  complex  APSE)  tends  to  "lock  in"  a  project  to  an  APSE 
unless  a  very  serious  limitation  threatens  the  project. 

In  the  experience  of  Sonicraft,  this  is  bad  for  the  project 
because  vendors  tend  to  be  much  more  responsive  to  project 
needs  if  they  know  they  are  facing  good  competition  from 
another  APSE  vendor. 

10.  15.  8  Compiler 

Diversity  in  the  implementation  of  APSEs  limits  the  ability  of 
a  project  to  switch  compilers  when  an  apparently  better  one 
becomes  available  after  one  has  already  been  used  for  a  while. 
This  is  because  the  investment  in  APSE  training  for  the 
existing  coo^iler  will  probably  be  useless  for  the  APSE  that 
comes  with  the  new  compiler,  and  additional  time  and  money  will 
be  needed  for  training  in  the  new  APSE. 


10.  IS.  9  Facilities 
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Diversity  in  implementation  of  APSEs  may  increase  facilities 
costs  if  the  new  APSE  requires  a  different  host  computet 
configuration.  Sonicraft  experienced  this  when  it  purchased  the 
Alsys  compiler  to  use  to  verify  correctness  of  code  before 
submitting  a  compilation  to  the  ALS.  This  was  necessary  because 
of  the  ALS  very  slow  compilations  and  sometimes  puzzling 
compile  error  messages.  The  problem  was  that  the  Alsys  compiler 
was  not  available  to  run  on  the  VAX  host  that  Sonicraft  was 
using,  so  an  additional  host  computer  had  to  be  acquired.  (In 
this  'case  the  host  was  an  ISM  PC/AT  compatible,  which  was  not 
very  expensive  and  which  could  be  used  for  other  purposes,  so 
the  penalty  was  not  severe.  ) 


10.15.10  Stability 

Diversity  in  implementation  of  APSEs  affects  project  stability 
from  the  viewpoint  of  the  customer  especially.  Although  not  as 
drastic  as  a  change  in  the  specifications  in  the  deliverable 
system,  ,a  change  in  the  APSE  does  affect  the  maintenance 
concept  and  does  have  some  cost  due  to  its  change. 

The  customer  is  usually  willing  to  change  APSEs  if  it  can  be 
shown  that  a  change  in  specifications  to  the  deliverable 
system  is  the  only  alternative.  Other  than  that,  many  customers 
would  probably  rather  have  the  project  stability  than  a  gain  in 
system  performance  that  isn't  really  necessary. 
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10.  16  POOR  PERFORMANCE  OF  ADA  TOOLS 

In  recent  years,  a  number  of  software  support  tools  have  been 
developed  for  use  on  Ada  development  efforts.  However,  due  to 
the  fact  that  most  of  these  tools  have  been  developed  for 
project-specific  purposes  or  as  a  part  of  internal  R£0  efforts, 
these  tools  have  generally  provided  poor  performance.  Some  of 
the  tools  that  have  been  developed  include  compilers,  linkers, 
importers,  exporters,  debuggers,  editors,  pretty  printers,  PDL 
processors,  .library  managers,  and  library  software 
(mathematical,  etc.). 

The  poor  performance  of  these  Ada  tools  has  had  an  adverse 
impact  in  some  areas  of  programmer  productivity.  The 
programmers  have  had  to  expend  significant  effort  to  develop 
workarounds  in  those  (frequent)  cases  where  the  tools  have  not 
performed  as  expected  (advertised).  The  tools  vendors  have 
provided  poor  documentation  and  inadequate  tool  support,  and  a 
number  of  the  tools  have  been  delivered  with  bugs  in  them. 

This  situation  should  improve  as  the  Ada  software  development 
environment  continues  to  mature  and  more  tools  users  provide 
fe«J(back  to  the  tool  vendors  concerning  the  performance  of  the 
tools. 

10. 16. 1  Efficiency 

A  number  of  the  currently  available  Ada  tools  are  immature. 
The  poor  performance  of  these  tools  can  have  an  adverse  impact 
on  overall  system  efficiency.  In  particular,  the  performeuice 
of  the  compiler  currently  has  the  greatest  impact  on  system 
efficiency.  The  compiler  generates  t±e  object  code  for  the  Ada 
applications  programs  and  also  generates  the  R5L  code,  which 
operates  in  conjunction  with  the  applications  programs. 

Two  of  the  major  problems  to  be  addressed  in  the  development  of 
Ada  systems  are  the  inefficiency  of  the  object  code  generated 
by  the  Ada  compiler  and  the  overhead  associated  with  operation 
of  the  RSL  programs.  The  object  code  generated  by  the  compiler 
runs  relatively  slowly  and  uses  an  extensive  amount  of  memory 
when  compared  to  the  use  of  other  programming  languages  for 
embedded  real-time  applications.  The  RSL  performs  a  number  of 
run-time  functions  for  the  applications  programs,  but  also 
generates  excessive  system  sizing  and  timing  overhead. 

10. 16. 2  Reliability 

A  number  of  the  existing  Ada  software  tools  are  immature.  They 
have  not  yet  been  proven  by  use  in  a.ctual  Ada  system 
development*  efforts  and  in  some  cases  still  have  bugs  in  them. 
Since  the  compiler-generated  object  code  for  the  applications 
programs  and  the  RSL  both  reside  in  the  target  machine,  any 
bugs  that  are  present  in  these  programs  will  reduce  overall 
system  reliability. 
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10. 16.  3  Benc'haark 

Because  a  number  of  the  existing  Ada  software  tools  provide 
poor  performance,  it  is  important  to  perform  extensive 
benchmarking  of  the  tools  before  deciding  whether  or  not  to  use 
them  for  a  particular  project.  Benchmarking  provides  an 
evaluation  of  the  actual  performance  of  a  tool  in  a  specific 
development  and  applications  environment. 

Benchmarking  also  helps  to  provide  an  evaluation  of  claimed 
(expected]  tool  performance  vs.  actual  performance. 

For  example,  the  execution  time  required  by  the  RSL  to  process 
an  interrupt  can  have  a  major  impact  on  system  performance.  A 
twenty  percent  increase  in  the  time  required  to  handle  an 
interrupt  can  adversely  impact  system  performance,  particularly 
if  the  system  processes  a  large  number  of  interrupts. 

10.  16.  4  ^  Optimization 

The  poor  performance  of  a  number  of  the  existing  Ada  software 
tools  currently  forces  the  applications  developers  to  perform 
extensive  Ada  optimization  to  meet  system  requirements.  This 
optimization  can  include  the  use  of  special-purpose  hardware 
and  software,  modifications  to  the  compiler  and  RSL,  and  other 
techniques.  However,  while  increasing  overall  system 
performance,  optimization  can  also  have  an  adverse  impact  on 
certain  system  characteristics.  Extensive  optimization  can 
reduce  system  reliability,  maintainability,  euid  portability 
while  increasing  system  complexity. 

10. 16. 5  Development  Environment 

The  poor  performance  of  the  Ada  software  tools  that  comprise 
the  applications  development  environment  can  have  an  adverse 
impact  on  project  productivity.  For  example,  the  compilation 
speed  of  an  Ada  compiler  can  make  a  major  difference  in  the 
productivity  of  the  development  effort.  A  compilation  speed  of 
100  lines  per  minute  as  opposed  to  200  lines  per  minute  can 
cause  a  significant  reduction  in  programmer  productivity, 
particularly  if  a  large  number  of  recompiles  are  performed. 

10.  16.  6  Vendor  Interface 

Due  to  the  poor  performance  of  some  of  the  available  Ada  tools, 
and  because  some  of  the  tools  still  have  bugs  in  them,  it  is 
important  to  establish  an  interface  with  the  tool  vendors. 
This  interface  will  allow  the  vendor  to  provide  support  in 
fixing  bugs  in  the  software  tools  and  will  also  provide  a 
source  of  information  concerning  ways  to  obtain  optimum 
performance  from  the  tools. 
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10.  16.  7  Cost 

The  poor  performance  of  a  number  of  existing  Ada  tools  can  have 
adverse  impacts  on  system  performance  and  programmer 
productivity/  thus  increasing  the  overall  system  development 
cost. 

10. 16.  8  Schedule 

The  poor  performance  of  a  number  of  the  existing  Ada  tools  can 
have  an  adverse  impact  on  system  performance  and  programmer 
productivity/  thus  increasing  the  length  of  the  development 
schedule. 
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10.  17  DIFFERENCE  IN  BENCHHARKIN(r  ADA  SYSTEMS 

Benchmarks  can  be  of  two  main  types>  those  that  are  used  to 
time  and  site  portions  of  application  code  (usually  using 
breadboard  hardware)  and  those  that  are  used  to  evaluate 
compilers  and  other  support  tools.  It  is  the  benchmark 
software  for  support  tools  that  is  addressed  in  this  problem. 

Ada  is  a  very  powerful,  but  also  very  new,  programming  language 
for  embedded,  mi  ss  i  on-c  r  i  t  ic  al  software.  (Whenever  an 
application  is  being  planned  that  is  significantly  different 
from  previous  experience  in  the  software  organization 
performing  the  task,  benchmarking  is  normally  relied  upon  to 
scope  out  the  job.  Unfortunately,  the  very  constructs  that 
make  Ada  a  valuable  embedded  software  language  are  hard  to  find 
in  widely  available  benchmarks. 

The  benchmark  most  often  cited  by  compiler  vendors  seems  to  be 
the  Dhrystone,  which  has  none  of  the  new  Ada  constructs 
(tasking,  interrupt  handling,  direct  addressing,  etc. )  which 
make  it 'superior  to  languages  like  Pascal  for  embedded  systems. 
In  comparison  to  real  application  code,  such  as  the  Sonicraft 
MEECN  system,  the  Dhrystone  benchmatrk  is  too  optimistic  in  both 
compilation  speed  (lines  of  code  per  minute)  and  in  object  code 
size  (bytes  per  line  of  source  code).  Errors  could  be  a 
problem  if  they  are  not  discovered  until  application  code 
begins  to  emerge  somewhere  around  the  end  of  the  Detail  Design 
Phase.  The  project  is  supposed  to  be  ready  to  code  very 
heavily  at  that  point,  yet  will  find  itself  with  undersized 
computer  resources,  both  for  the  host  and  the  target,  if  the 
Dhrystone  numbers  had  been  believed. 

One  approach  taken  to  deal  with  this  problem  was  reported  by  M. 
Kamrad  of  Honeywell  at  the  Jan  87  SIGAda  Conference.  Be 
recommended  postponing  the  decision  of  how  many  processors  to 
put  in  the  system  and  what  software  functions  run  in  each  until 
the  coding  has  matured  enough  that  its  final  size  and  timing 
requirements  are  known. 

According  to  D.  L.  Doty  [Ref],  this  can  be  a  long  wait.  Be  has 
observed  size-estimate  errors  greater  than  100  percent  at  the 
RFP  stage,  75  percent  up  to  the  Preliminary  Design  Review,  and 
50  percent  up  to  the  Critical  Design  Review. 

But  all  this  leaves  the  compiler  vendor  in  a  quandry  if  he  is 
trying  to  introduce  a  new  compiler.  Unless  he  can  test  it 
against  a  real  application  in  Ada  which  is  already  running 
under  another  Ada  compiler,  it  will  be  difficult  to  convince 
potential  customers  that  this  new  compiler  can  really  handle  an 
embedded  Ada  application. 
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[R«f]  0.  L.  Doty,  P.  J.  Nelson,  and  R.  R.  Stewart,  "Software  Cost 
Estimation  Study:  Guidelines  for  Improved  Software  Cost 
Estimating"  (Vol  2},  Final  Technical  Report  by  Doty  Associates, 
Inc.,  for  Rome  Air  Development  Center  (RADC-TR-77-220) , Griff iss 
Air  Force  Base,  NY,  Aug  77,  145pp  as  cited  by:  W.  Myers,  "A 
Statistical  Approach  to  Scheduling  Software  Development",  IEEE 
Computer,  Dec  7  8 

10. 17. 1  Efficiency 

Foe  applications  where  target  efficiency  is  important,  the 
availability  of  an  appropriate  benchmarking  program  early  in 
the  development  cycle  is  very  important.  Efficiency  is  needed 
where  the  computer  resources  (memory  size  and  speed  of 
execution)  are  limited  by  physical  size,  weight,  power  or 
cooling  requirements.  In  mission-critical  software  applications 
it  is  not  unusual  to  be  limited  by  all  these  requirements. 

The  inability  to  differentiate  between  compilers  that  may  be 
suitable  for  an  application,  or,  worse,  false  information  about 
compiler  performance  on  that  application,  can  damage  the  target 
efficiency  actually  achieved  quite  severely.  In  some  cases  it 
may  be  necessary  to  buy  a  second  compiler  that  generates  more 
efficient  code. 

10.17.2  Maintenance 

The  use  of  inappropriate  benchmarks  to  select  a  compiler,  thus 
defining  target  code  efficiency,  and  to  specify  embedded 
computer  resources  can  lead  to  a  situation  where  considerable 
optimization  is  required  to  get  everything  to  fit  in  memory  and 
still  execute  within  timing  constraints.  Compiler  optimization 
can  cause  problems  if  it  is  unique  to  a  project,  causing 
surprises  in  the  maintenance  phase  of  the  life  cycle  when 
seemingly  straight-forward  changes  are  inserted. 

More  serious  problems  occur  when  obscure  source  code, 
especially  "tricky"  code  that  depends  on  a  side-effect  to  work, 
is  used  to  meet  the  system  requirements.  Program 
maintainability  depends  mostly  on  program  understandability 
[Ref],  so  obscure  code  is  therefore  very  difficult  to  maintain. 

[Ref]  G.  M.  Berns,  "Assessing  Software  Maintainability", 
Communications  of  the  ACM,  Jan  84 

10.  17.  3  Expandability 

The  use  of  an  inappropriate  benchmark  can  lead  to  the  selection 
of  a  compiler  that  unnecessarily  wastes  embedded  computer 
resources  and  to  specifications  that  are  much  tighter  than 
anticipated.  Even  when  this  does  not  cause  the  project  to  fail 
by  requiring  massive  rework,  the  available  resources  are 
invariably  stretched  almost  to  the  breaking  point  in  the 
process  of  solving  the  problems. 
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In  this  situation  there  is  simply  nothing  to  spate  for  future 
expandability  unless  the  procuring  agency  had  specified  unused 
computer  resources  to  be  in  the  delivered  product,  and  had  the 
further  strength  to  avoid  sacrificing  this  reserve  when  the 
project  got  in  trouble  because  of  the  inappropriate  benchmark 
programs. 

10.  17.  4  Tool  Ose 

The  use  of  inappropriate  benchmarks  can  ruin  the  selection  of 
the  most  important  tool  on  the  project,  the  Ada  compiler 
itself.  At  the  present  state  of  technology  there  is  not  often 
much  choice  available  in  compilers,  but  the  differences  between 
them  are  oft'.n  quite  significant.  If  the  wrong  one  is  selected 
because  it  did  a  good  job  on  an  inappropriate  benchmark 
program,  the  project  will  usually  suffer,  especially  if  it  is 
later  proven  that  the  selected  compiler  has  limitations  that 
prevent  it  from  supporting  the  specified  software  performance. 

10. 17. 5  Benchmark 

The  problem  subcategory  BENCHMARKING  here  refers  to  the  sizing 
and  timing  estimates  obtained  on  teal  application  code  of 
critical  routines  or  algorithms.  Usually  these  benchmarks 
differ  from  the  deliverable  code  only  in  their  mote  thorough 
treatment  of  special  cases  or  in  exception  handling  (if  they 
differ  at  all}.  The  support  code  benchmarks  which  are  being 
discussed  in  this  problem  treatment  are  general-purpose 
routines  often  obtained  from  ^n  outside  source.  The  best 
support  code  benchmarks  are  usually  widely  used  in  government, 
industry  and  academia  by  designers  interested  in  evaluating  Ada 
compilers. 

Inappropriate  support  code  benchmarks  can,  as  discussed 
elsewhere  in  this  problem,  cause  application  developers  to 
obtain  an  unsuitable  compiler  whose  performance  is  over¬ 
estimated  by  the  support  code  benchmark.  This  must  be  later 
corrected  by  reallocating  software  functions  to  hardware 
(extensive  rework},  purchase  of  a  higher  performance  compiler, 
or  optimizing  source  code.  Sometimes  it  requires  some 
combination  of  these  to  recover  from  the  problem, 

i^hen  the  compiler  must  be  replaced  this  invariably  impacts  any 
work  that  has  been  performed  in  application  benchmarking  since 
this  work  is  done  in  the  earliest  possible  design  phases.  In 
fact  it  is  often  the  application  benchmarking  that  demonstrates 
that  the  compiler  benchmark  was  inappropriate. 

10.17.6  System  Sizing 

The  use  of  inappropriate  benchmarks  can  lead  to  errors  in 
target  processor  memory  requirements  that  can  be  quite 
substanrial.  If  the  application  happens  to  be  one  where  memory 
is  extremely  expensive  or  even  impossible  to  add  (using  then- 
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current  technology),  this  could  force  an  abortion  of  the 
project. 

Projects  with  radiation-hardened  memory  requirements,  in  which 
reliability  goes  down  in  direct  proportion  to  memory  size,  and 
projects  with  severe  size,  weight,  power  and  cooling 
limitations  (such  as  on-board  processors  in  a  small  missile), 
are  especially  vulnerable  to  memory  sizing  problems. 

10.17.7  System  Timing 

When  a  compiler  produces  more  object  code  than  expected  (bytes 
per  line  of  Ada  source  code),  the  execution  speed  of  a 
functional  module  also  increases.  Experience  at  Sonicraft  with 
code  generated  using  a  steadily- improving  compiler  indicates 
that  the  relationship  is  quite  direct. 

In  systems  where  hardware  cannot  be  added  to  replace  Ada 
routines  that  are  found  to  be  too  slow,  and/or  where  the 
permissible  amount  of  assembler  code  has  already  been  used  for 
Ada  r'e  p  1  ac  e  me  n  t  s  ,  this  can  be  disastrous.  Ose  of  an 
inappropriate  benchmark,  by  delaying  the  time  at  which  the 
speed  problem  becomes  known,  can  cause  either  or  both  of  these 
situations  to  occur. 

10. 17. 8  POL  Processoc 

The  POL  processor  is  often  used  to  help  make  target  memory  and 
speed  estimates  during  the  Preliminary  Design  Phase  and 
especially  during  the  Detail  Design  Phase.  The  use  of  an 
inappropriate  benchmark  can  throw  Off  the  resulting  estimates 
enough  to  force  a  substantial  rewrite  of  the  PDL  to  meet  system 
requirements. 

10.  17. 9  Compiler 

The  use  of  an  inappropriate  benchmark  can  result  in  the 
selection  of  a  less-expensive  compiler  in  the  mistaken  belief 
that  it  is  good  enough  to  perform  the  Ada  application  at  hand, 
in  some  cases  it  can  even  mislead  one  into  thinking  that  then- 
current  Ada  compiler  technology  is  adequate,  when  in  fact  an 
Ada  waiver  or  a  substantial  reduction  of  the  functionality 
assigned  to  software  in  the  Software  Requirements  Analysis 
Phase  may  be  needed. 

10. 17. 10  Software  Requirements  Analysis 

The  use  of  an  inappropriate  benchmark  usually  leads  to  overly- 
optimistic  estimates  of  what  can  be  accomplished  in  software 
using  the  available  target  computer-  resources.  This  can  force 
a  project  to  regress  back  to  the  hardw are/software  allocation 
of  system  functions  when  the  truth  is  finally  learned.  If  this 
happens  fairly  late  in  a. project,  and/or  if  the  project 
deadline  cannot  afford  major  delay,  this  would  be  a  fatal  blow. 
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Slir.ilarly,  cost  constraints  could  preclude  the  major  rework 
that  might  be  needed. 

Benchmarks  can  also  cause  the  host  computer,  whic.h  is  usually 
selected  in  this  Phase,  to  be  grossly  undersized.  This  could 
lead  to  very  long  turn-around  times  for  compilations  unless 
unplanned  host  capacity  can  be  added.  This  kind  o£  activity 
may  not  kill  a  project,  but  has  been  known  to  be  detrimental  to 
the  careers  of  those  responsible  for  the  error. 

10. 17. 11  Preliminary  Design 

Errors  caused  in  target  memory  sizing  and  target  execution 
times  of  major  functions  become  part  of  the  Software 
Requirements  Specification  if  not  discovered  before  the 
Preliminary  Design  Phase  is  completed.  Since  application  code 
does  not  appear  in  significant  quantities  during  this  Phase 
(usually),  erroneous  benchmark  programs  can  cause  considerable 
damage  here. 

10. 17. 12  Detail  Design 

Erroneous  sizing  and  timing  specifications  caused  by  the  use  of 
inappropriate  benchmarks  are  often  discovered  in  the  Detailed 
Design  Phase,  usually  when  preparing  a  Critical  Design  Review 
demonstration  of  an  early  software  prototype.  As  such,  the 
error  is  usually  associated  with  this  Phase,  when  in  fact  the 
benchmarking  normally  occurs  in  earlier  phases. 

A  discovery  of  major  specification  errors  this  late  in  the 
program  costs  considerably  in  both  schedule  time  loss  and  in 
rework  costs.  If  the  system  hardware/sof tware  functional 
allocation  must  be  severely  changed,  this  benchmarking  problem 
could  easily  be  fatal  to  the  project. 

10.  17.  13  Facilities 

Inappropriate  benchmarks  can  cause  compile  times  on  the  host 
computer  selected  to  be  underestimated  by  very  large  amounts. 
Since  these  most  computers  often  have  long  lead  times,  require 
special  power  and  air  conditioning,  and  are  not  inexpensive, 
this  can  be  a  serious  problem. 

If  the  additional  facilities  eire  not  purchased,  the  increased 
compile  turn-around  time  will  reduce  progreusmer  efficiency  to 
the  point  where  more  staff  might  be  added,  reducing  efficiency 
even  more. 

10.  17.  14  Cost 

The  costs  that  can  be  incurred  by  using  inappropriate 
benchmarks  to  select  the  Ada  compiler  and  to  allocate  functions 
between  hardware  and  software  come  from  two  sources: 
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First,  the  target  computer  design  may  need  rewotk  because  it 
has  insufficient  resources  to  meet  the  specifications  which  the 
benchmarks  had  indicated  were  achievable. 

Second,  the  host  computer  may  be  too  slow  to  support  the 
project  because  the  benchmark  had  given  erroneous  values  ‘Of 
lines  of  code  compiled  per  minute  compared  to  what  was  being 
experienced  later  in  the  program  when  application  code  was 
compiled. 

10.' 17.  15  Schedule 

An  inappropriate  benchmark  can  hurt  schedule  mainly  by 
misleading  the  designer  as  to  what  embedded  computer  resources 
are  needed  to  meet  the  software  specifications,  perhaps  causing 
rework  all  the  way  back  to  the  functional  allocations  between 
hardware  and  software. 

A  second,  usually  less  important,  schedule  problem  can  be 
caused^  by  believing  that  the  compile  speeds  attained  using  the 
compiler  benchmark  can  be  attained  using  the  application  code. 
This  causes  the  host  computer  to  be  undersized,  giving  compile 
turn-around  times  that  are  much  longer  than  may  be  needed  to 
produce  the  Ada  code  in  a  timely,  efficient  manner.  When 
compile  turn-around  gets  to  be  overnight,  programmers  usually 
respond  by  doing  more  manual  checking  of  submitted  code, 
causing  delays  in  addition  to  those  caused  by  simple 
inefficiency. 

10. 17. 1€  Estimation 

The  whole  purpose  of  benchmarking  is  to  estimate  the  target 
computer  resources  and  the  host  computer  resources  needed  to 
satisfy  system  design  constraints.  A  benchmark  that  makes  very 
large  errors  in  doing  this  is  an  obvious  problem. 
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10.  18  LACK  OF  ADA  SOFTWARE  DEVELOPMENT  TOOLS 

Alchough  a  number  of  software  tools  have  been  developed  for  use 
in  Ada  environments,  there  is  still  a  variety  of  tools  that  are 
desirable  to  further  improve  the  productivity  and  performance 
associated  with  Ada  development  efforts.  Some  of  these  tools 
ate  currently  in  various  stages  of  development  (planning, 
design,  implementation,  testing). 

Some  of  the  tools  that  would  be  useful  for  Ada  efforts  include; 

*  Ada  Design  Generators 

*  Ada  Code  Generators 

*  Ada  Source  Code  Analyzers 
*_ Ada-oriented  Debuggers 
*'Ada  Syntax-directed  Editors 

*  Ada  Cost  Estimation  Models 

*  Ada  Project  Management  Tools 

*  Secure  Ada  Operating  Systems 
•'Automated  Ada  Test  Tools 

The  lack  of  Ada  tools  affects  the  overall  productivity  of 
development  efforts.  The  availability  of  these  tools  would 
decreases  the  number  of  development  activities  that  are 
currently  performed  manually.  It  would  also  reduce  the  overall 
development  effort  by  reducing  the  requirement  for  applications 
programmers  to  develop  their  own  project-specific  tools.  The 
availability  would  also  improve  the  consistency  of  the  products 
developed  on  Ada  projects  and  would  help  impose  and  enforce 
project  methodologies  and  development  standards. 

10.  18.  1  Reusability 

The  current  lack  of  Ada  software  development  tools  forces  the 
applications  programmers  to  develop  their  own  project-specific 
tools  to  perform  those  functions.  However,  these  tools  are 
generally  not  built  to  be  reusable  in  a  variety  of  different 
applications.  This  is  due  to  the  additional  cost  of  developing 
a  reusable  tool  as  opposed  to  developing  a  tool  which  is  only 
to  be  used  on  a  particular  project. 

10.18.2  Development  Environment 

In  an  effort  to  provide  a  more  powerful  and  flexible 
environment  for  the  development,  a  number  of  Ada  software  tools 
have  been  developed  and  more  are  being  developed.  But  due  to 
the  immaturity  of  Ada,  there  are  a  number  of  tools  that  are  not 
yet  available  which  would  prove  to  be  very  beneficial  for  Ada 
development  efforts.  Even  though  these  tools  are  not  yet 
available,  some  of  them  are  in  various  stages  of  development 
(conceptualization,  design,  Implementation,  test).  These 
tools  include: 
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*  Ada  Cost  Estimation  Tools 

*  Ada-oriented  Debuggers 

*  Ada  Project  Management  Tools 

*  Secure  Ada  Operating  Systems 

*  Automated  Ada  Test  Tools 

*  Ada  Source  Code  Generators 

*  Ada  Design  Tools 

As  these  tools  become  available  to  the  Ada  applications 
programmerSf  a  number  of  the  Ada  development  activities  that 
are  currently  manual  or  partially  automated . w ill  be  fully 
automated. 

10. 1 8.  3  Cost 

The  current  lack  of  Ada  software  development  tools  forces  the 
applications  programmers  to  develop  project-specific  tools 
which  perform  the  required  functions.  The  development  of  these 
tools  increases  the  overall  cost  of  the  Ada  development  effort. 

10.  1 8.  4  Schedule 

The  current  lack  of  Ada  software  development  tools  forces  the 
applications  programmers  to  develop  their  own  project-specific 
tools  which  perform  the  specific  functions.  The  development  of 
these  tools  can  lengthen  the  overall  system  development 
schedule. 
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10.19  ADA  LANGUAGE  CCMPLEXITY 

The  complexity  o£  the  Ada  language  makes  it  difficult  to  learn, 
use  effectively,  and  test  (validate}.  The  Ada  language 
requires  extensive  training  for  programmers  to  learn  language 
syntax,  proposed  development  methodologies,  software 
engineering  standards,  and  implementation  issues  for  real-time 
embedded  systems. 

The  Ada  language  is  also  difficult  to  use  effectively  and 
efficiently.  For  example,  the  current  inefficiency  of  Ada 
compilers  creates  an  environment  where  unchecked  use  of  certain 
Ada  features  (tasking,  generics,  etc..)  can  cause  significant 
impacts  on  system  performance.  Also,  Ada  development 
methodologies  and  programming  standards/conventions  are  still 
being  established. 

The  power  and  complexity  of  the  Ada  programming  language  can 
also  make  it  difficult  to  test  and  validate  an  Ada  system.  The 
functional  and  performance  impacts  of  the  RSL,  a  very  complex 
piece  of  software,  play  an  important  part  in  the  testing 
process. 

1C.  19.  1  Verifiability 

The  complexity  of  the  Ada  programming  language  and  run-time 
environment  makes  it  difficult  to  verify  Ada  systems. 

While  the  Ada  programming  language  has  a  number  of  features 
which  provide  valuable  support  for  state-of-the-art  software 
engineering  methodologies,  the  complexity  of  the  language 
(packages,  tasking,  generics,  etc..)  makes  it  a  very  difficult 
language  to  verify  for  program  correctness. 

In  the  target  environment  at  run-time,  an  applications  program 
can  perform  tasking  in  a  multiprocessor  system,  create,  access, 
and  deallocate  portions  of  memory,  and  access  specific  memory 
locations.  Also,  the  RSL  provides  a  number  of  run-time 
functions  such  as  task  scheduling,  memory  management,  and 
others.  These  functions  combine  to  create  a  complex  run-time 
environment,  in  which  a  large  portion  of  the  code  resides  in 
the  RSL.  The  complexity  of  the  RSL,  combined  with  the  fact 
that  most  applications  developers  are  unfamiliar  with  the 
operation  and  performance  of  the  RSL,  makes  it  difficult  to 
verify  an  Ada  system. 

10.19.2  Complexity 

The  Ada  language  provide  a  number  of  language  features 
(packages,  tasking,  generics,  etc..)  which  support  state-of- 
the-art  software  engineering  methodologies.  However,  the  use 
of  these  features  greatly  increases  the  complexity  of  the  Ada 
language  and  makes  the  language  much  more  difficult  to  learn 
and  use  effectively. 
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The  complexity  of  the  Ada  language,  the  variety  of  different 
compiler  implementations,  and  the  extensive  run-time  overhead 
associated  with  the  RSL  are  among  the  issues  that  must  be 
addressed  by  an  Ada  applications  programmer.  These  issues 
require  that  an  applications  programmer  have  a  good 
understanding  of  the  Ma  language  and  a  working  knowledge  of 
the  target  (run-time)  environment  in  order  to  effectively  use 
Ada  to  develop  real-time  embedded  systems.  If  an  applications 
programmer  does  not  have  this  knowledge,  there  is  a  high 
probability  that  the  developed  system  will  be  inefficient  and 
difficult  to  verify. 

The  extensive  amount  of  Ada  training  that  is  required  for  J^a 
applications  programmers  is  a  direct  result  of  the  complexity 
of  the  language.  The  training  helps  to  ensure  that  the 
applications  programmers  use  the  Ada  language  as  it  was 
intended  to  be  used,  understand  the  Ada  implementation  details, 
and  address  critical  real-world  issues  in  the  system  design. 

10.19.3  Detail  Design 

The  complexity  of  the  Ada  programming  language  can  increase  the 
amount  of  effort  required  in  the  Detailed  Design  Phase  of  Ma 
projects  when  compared  to  other  languages.  The  Detailed  Design 
Phase  is  the  point  in  the  project  where  the  proposed  Ada 
implementation  approach  is  developed.  It  is  also  the  point 
where  the  developers  begin,  in  detail,  to  assess  the  impact  of 
Ada  implementation  decisions  on  system  performance. 

Due  to  the  complexity  of  Ada,  the  resulting  detailed  design 
should  be  reviewed  extensively  to  maximize  the  effective  and 
efficient  use  of  the  Ada  language,  particularly  in  light  of  the 
system  performance  problems  associated  with  Ada  systems.  The 
applications  developers  should  also  identify  as  many  of  the 
system  optimization  requirements  as  possible  and  incorporate 
them  into  the  system  design.  These  reviews  can  significantly 
increase  the  effort  required  to  develop  a  detailed  design  for 
Ada  projects. 

10.19.4  Personnel  Resources 

The  complexity  of  the  Ada  programming  language  requires  that 
the  applications  programmers  have  previous  experience  with 
high-level  languages  (such  as  Pascal),  and,  in  particular, 
languages  that  are  commonly  used  in  the  development  of  real¬ 
time  embedded  systems. 
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10.  20  CUSTOMIZATION  OF  RUN-TIME  SUPPORT  LIBRARY 

When  an  Ada  compiler  and  its  respective  run-time  support  code 
is  validated,  it  is  on  a  target  system  specified  by  the 
compiler  developer.  The  problem  is  that  an  applications  user  of 
the  compiler  will  usually  have  a  different  configuration 
(memory  'map,  I/O  map)  for  their  particular  system.  Also,  the 
user  may  desire  different  default  values  for  their  run-time 
application,  such  as  the  task  stacks.  Instead  of  a  four 
kilobyte  default,  as  experienced  on  Sonicraft’s  MEECN  project 
they  may  elect  to  have  a  three  kilobyte  default.  Therefore,  the 
applications  user  must  modify  or  customise  the  run-time  support 
code.  To  get  this  type  of  customization  the  user  will  need  to 
recompile  the  run-time  support  library.  If  the  user  desires  to 
perform  this  task  himself,  he  must  usually  purchase  the  source 
code  rights  for  the  RSL  and  train  some  people  on  how  to  perform 
the  required  task.  The  other  option  is  to  contract  the  vendor 
to  make  the  required  modifications.  Either  course  of  action 
will  add  more  'cost  to  the  development  of  the  application 
program.  ^ 

Sonicraft  discovered  on  its  own  Ada  projects  that  the  ALS  run¬ 
time  software  needed  to  be  reconfigured  for  memory  map 
allocation,  interrupt  vector  addresses,  and  Input/Output 
addresses  for  Intel's  PIC  and  PIT  chips.  Further,  RSL  code  had 
to  be  repackaged  to  allow  for  better  selective  linking  and 
modified  to  remove  unused  8087  code  and  to  reduce  interrupt 
overhead. 

10.  20.  1  Maintenance 

Customization  of  the  Run-time  Support  Library  will  increase  the 
cost  to  maintain  the  RSL  and  the  application  program.  For 
example,  additional  documentation  will  be  required  for  any 
changes  required  to  support  the  execution  of  the  application 
program. 

10.  20.  2  Portability 

Whenever  software  is  customized  to  apply  to  a  unique  system 
configuration  it  sacrifices  portability.  Thus,  the  modification 
of  the  run-time  support  software  will  impact  any  efforts  to 
import  the  application  to  another  Ada  environment. 

10.  20.  3  Reusability 

Due  to  the  customization  of  the  run-time  software,  the 
reusability  is  reduced  if  the  system  configuration  changes.  _  If 
configuring  the  run-  time  software  can  be  done  by  setting 
pragmas  in  the  application  source  code  the  loss  of  reusability 
could  be  minimized. 
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10.  21  LACK  OP  EXPERIENCED  ADA  PROGRAMMERS 

As  we  in  the  Ada  community  have  heard  so  often,  Ada  is  "not 
just  another  high  order  language",  but  is  a  whole  new  approach 
to  software  design.  Indeed,  many  respected  individuals  feel 
that  the  major  contribution  that  Ada  will  make  is  to  train 
programmers  in  the  use  of  modern  software  design  techniques 
[Ref  1].  When  we  speak  of  the  problem  of  not  enough  experienced 
Ada  programmers,  it  is  in  this  broader  context  that  we  see  the 
problem. 

Experience  at  Sonicraft  is  that  a  fresh  graduate  with  a  CS 
degree  can  learn  Ada  syntax  well  enough  in  about  three  weeks  to 
start  making  useful  contributions  to  a  project.  Despite  the 
complaints  about  Ada  being  "too  complex",  it  turns  out  in 
practice  that  some  of  the  complex  features  need  only  be  used  by 
a  small  percentage  of  design  team  members. 

Teaching  a  methodology  takes  far  longer  in  the  experience  of 
Sonicraft.  Formal  courses  typically  go  for  two  or  three  weeks 
at  two  or  three  hours  per  day  (with  homework),  but  it  takes 
actual  project  experience  before  most  people  really  understand 
the  value  of  a  methodology  and  become  advocates  of  it.  Without 
this  kind  of  full  support,  most  methodologies  are  reduced  to 
being  an  extra  paperwork  burden  in  the  minds  of  the 
programmers. 

Formal  courses  are  another  problem  because  hiring  is  usually 
done  over  a  period  of  time,  rather  than  hiring  the  first  few 
applicants  who  meet  the  minimum  qualifications.  Putting 
untrained  people  on  the  job  while  they  are  waiting  for  the  next 
class  to  start  brings  on  the  infamous  Brooks'  Law  effects, 
where  the  addition  of  additional  programmers  slows  down  the 
team  [Ref  2].  This  happens  because  the  experienced' people  must 
spend  considerable  time  explaining  to  the  new  people  some  of 
the  things  they  would  normally  have  learned  in  the  classes. 

Finally,  the  supply  of  experienced  Ada  programmers  is  not  easy 
to  measure.  At  the  November  86  SIGAda  Conference,  for  example, 
it  was  reported  that  the  biggest  shortage  in  Ada-trained  people 
is  among  managers.  The  supply  of  programmers  was  greater  than 
the  number  of  people  actually  doing  Ada  work.  This  result 
flies  in  the  face  of  experience  in  hiring  at  Sonicraft,  where 
over  a  four  year  period  over  forty  designers  were  hired  to  do 
Ada  work  and  only  one  of  them  had  any  Ada  experience  on  the 
job.  Very  few  of  the  CS  majors  had  a  course  that  even  used  Ada 
until  about  1986. 

This  apparent  discrepancy  between  the  reported  oversupply  and 
the  experienced  shortage  of  Ada  pcogreunmers  could  have  been  a 
local  shortage  or  it  could  have  been  pure  chance.  But  it  also 
could  have  been  caused  by  large  firms  training  massive  numbers 
of  people  in  Ada  in  anticipation  of  future  Ada  contracts.  This 
would  indeed  cause  an  oversupply  to  be  measured  if  one  counted 
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everyone  who  went  through  these  -courses  as  an  experienced  Ada 
programmer. 

[Ref  1]  F.  P.  Brooks, "No  Silver  Bullet",  IEEE  Computer,  April  87 

[Ref  2]  F.  P.  Brooks,  "The  ^tytfaical  Man-Month",  1975,  Addison- 
Wesley,  Reading,  Mass. 

10. 21. 1  Efficiency 

When  Sonicraft  implemented  the  MEECN  Ada  project,  there  was  a 
memory  sizing  problem  discovered  after  much  of  the  code  had 
been  written.  By  having  the  most  experienced  team  members  go 
over  the  code  of  the  less  experienced  members  in  code 
walkthroughs,  a  very  substantial  savings  in  both  target  code 
size  and  run  time  was  achieved. 

Ada  is  a  complex  language.  While  it  is  true  that  after  only  a 
few  weeks  a  programmer  will  know  the  syntax  well  enough  to  do 
useful  work,  the  sections  of  code  that  require  detailed  Ada 
knowledge  to  make  bast  use  of  Ada  features  for  efficiency  are 
best  left  to  the  more  experienced  Ada  programmers. 

This  is  also  a  management  experience  problem,  since  other  high 
order  languages  rarely  show  this  much  sensitivity  to 
experience.  A  manager  doing  his/her  first  Ada  project  can 
easily  misassign  critical  code  sections,  which  then  must  later 
be  reworked. 

10.  21.  2  Risk 

The  longer- than-normal  delay  between  hiring  an  inexperienced 
Ada  programmer  and  the  time  that  he  is  "fully  productive" 
(usually  defined  as  spending  less  than  ten  percent  of  the  time 
in  training  or  education-related  tasks)  increases  the  risk  to 
projects  being  done  in  Ada.  Ada  projects  are  hard  to  estimate 
accurately  [Problem  #23].  Unless  the  developer  has  trained  a 
pool  of  Ada  programmers,  who  then  may  have  been  assigned  to 
interruptible  tasks  (such  as  overhead  R&D  projects) ,  they  may 
find  it  impractical  to  train  and  then  add  the  required  staff  in 
time  to  meet  project  delivery  dates. 

This  aspect  of  the  problem  is  more  critical  when  the  project  is 
fairly  small,  making  the  duration  of  each  phase  only  a  few 
months.  If  an  entire  phase  of  the  life  cycle  elapses  before  an 
underestimated  project  is  staffed  with  fully  trained  Ada 
designers,  the  customer  will  probably  consider  the  resulting 
schedule  slippage  a  major  one. 

10.  21.  3  Training 

Inexperience  affects  training  in  methodologies  because  a  mind¬ 
set  is  required  to  use  Ada  properly.  Zn  this  regard  it  is 
often  better  to  train  fresh  Computer  Science  graduates  than 
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experienced  FORTRAN  prograsuners  who  have  never  learned  one  of 
the  structured  methodologies. 

10.  21.  4  Tool  Dse 

Especially  because  of  the  Inefficiencies  of  current  Ada 
compilers  [Problem  #7],  the  use  of  tools  like  profilers  (they 
tell  how  often  each  line  or  code  segment  is  executed,  helping 
to  direct  attention  to  the  often,  innocuous  code  that  is 
devouring  the  available  computer  resources)  is  important. 

10.  21.  5  Reviews 

Because  of  the  complexity  of  the  Ada  language,  it  takes  about  a 
year,  in  Sonicraft's  experience,  to  acquire  expertise  in  the 
areas  needed  to  write  consistently  efficient  source  code.  Peer 
reviews  in  the  form  of  structured  design  or  code  walkthroughs 
are  essential  for  the  work  of  the  inexperienced  Ada  programmers 
especially,  but  if  the  project  has  few  experienced  Ada 
programmers  available  they  could  spend  so  much  time  in  reviews 
that  little  work  gets  done.  This  is  significant  because  they 
regularly  produce  two  to  three  times  as  much  as  new  graduates 
with  basic  Ada  and  methodology  training. 

10.  21.  6  Method  Type 

Any  new  methodology  is  easier  to  learn  for  a  person  who  already 
is  fully  trained  in  the  use  of  at  least  one  other  because  of 
the  "mindset"  problem  that  needs  to  be  overcome.  Experienced 
Ada  programmers  are  almost  certain  to  be  trained  in  a 
methodology  [Problem  #21  Definition],  whereas  those 
Inexperienced  in  Ada  are  frequently  not. 

Since  some  methodologies  are  harder  to  learn  than  others 
(Jackson  seems  harder  than  Yourdan,  for  example),  this  could  be 
a  factor  in  selecting  a  methodology  if  few  on  staff  bad  ever 
learned  one. 

10.  21.  7  Document 

Ada  has  a  number  of  new  constructs  that  affect  what  had  once 
been  fairly  standard  concepts  in  documentation.  As  an  example, 
how  does  the  concept  of  Visibility  eiffect  the  definition  of 
Module  Coupling?  [Ref]  Bow  would  you  show  concurrent  tasking  on 
flow  diagrams?  What  symbols  do  you  use  to  show  tasking  or 
packag ing? 

Even  experienced  Ada  programmers  have  difficulty  answering 
these  kinds  of  questions,  and  the  problem  gets  worse  with 
inexperience  in  Ada. 

[Ref]  S.  S.  Watson,  "Ada  Modules*,  Ada  Letters,  vii.  4-7  9  to  4-84, 
1987 
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10.  21.  3  Benchisark 

The  Ada  inexperience  on  a  project  could  invalidate  some  of  the 
code  benchmarking  dona  on  breadboard  or  brassboard  hardware 
because  of  the  unfamiliarity  with  the  mote  complex  Ada 

features.  The  area  of  hardware  interfaces  is  where  many  of 
these  features  are  found,  so  it  might  be  easy  to  be 

fooled  as  to  what  is  rsaily  happening  during  a  test. 

bonicraft  was  forced  to  assign  an  experienced  Ada  software 
engineer  full  time  to  the  brassboard  to  make  sure  that  all 
benchmarks  were  dona  correctly. 

10.  21.  9  Optimisation 

With  embedded  computer  resources  limited  by  system  size, 
weight,  power  and  cooling  constraints,  it  is  to  be  expected 
that  any  delivered  Ada  coda  will  be  compiled  with  the  optimizer 
turned  on.  It  is  true  for  any  language  that  optimization 
causes' subtle  changes  to  the  way  things  work,  but  for  Ada 
compilers  with  little  field  experience  the  changes  can  be  more 
noticeable. 

Inexperienced  Ada  programmers,  who  may  be  fully  occupied  in 
trying  to  understand  what  happens  normally,  may  miss  some 
important  changes  when  optimizing. 

10.  21.  10  System  Sizing 

Inexperienced  Ada  programmers  do  not  yet  understand  the 
Language  wail  enough  to  pick  the  most  size-ef f icient  constructs 
available.  In  the  experience  of  Sonicraft,  they  are  usually 
satisfied  whan  they  find  anything  that  seems  to  work,  and  it 
takes  a  review  by  mote  experienced  peers  to  suggest  more 
efficient  approaches. 

10.  21.  11  System  Timing 

Similar  to  the  system  sizing  discussion,  inexperienced  Ada 
programmers  profit  a  great  deal  from  suggestions  from  more 
experienced  Ada  programmers  tc  speed  up  their  code  as  required. 
Often  this  involves  the  use  of  tools,  such  as  the  profiler 
[Problem  121,  Tool  Osage],  with  which  they  may  not  yet  be 
familiar. 

10.  21.  12  PDL  Osage 

Even  before  coding  begins  the  price  of  Ada  inexperience  on  a 
project  surfaces.  Early  in  the  Detail  Design  phase  they  are 
expected  to  generate  documentation  using  a  Program  Design 
Language  [PDL] ,  which  on  Ada  projects  is  normally  a  compilable 
Ada  syntax  with  a  few  key  provisions  added. 

10.  21.  13  Mon-Ada  Software 
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Ada  software  usually  must  interface  with  another  language,  such 
as  Assembler,  in  an  embedded  microprocessor  project.  Even  if 
they  are  familiar  with  the  other  language,  designers 
inexperienced  in  Ada  are  open  to  additional  problems  as  they 
try  to  understand  this  interface. 

10.  21. 14  Vendor  Interface 

One  of  the  difficulties  experienced  at  first  by  Sonicraft  was 
the  interface  to  the  Ada  compiler  vendor.  As  one  of  the  first 
in  industry  to  attempt  a  mission-critical  weapon  system 
development  in  Ada,  Sonicraft  had  no  one  with  Ada  experience. 
Since  no  Ada  compilers  existed  that  could  meet  the  system 
requirements,  Sonicraft  contracted  to  Softech  to  retarget  the 
Army  ALS  to  the  Intel  8086  processor. 

While  Sonicraft  engineers  understood  what  they  needed  to 
accomplish,  having  had  experience  with  other  embedded 
microprocessor  systems,  they  found  it  very  challenging  to 
express  their  requirements  in  Ada  terms. 

Obviously  the  Sonicraft  experience  was  not  unique,  because  one 
of  the  issues  dealt  with  in  1983,  fast  interrupts,  was  still  a 
hot  topic  at  the  January  87  meeting  of  the  Ada  Run-Time 
Environment  Working  Group  (ARTEWG)  of  the  ACM  SZGAda. 

10.  21. 13  Prototype 

The  parts  of  the  Ada  language  learned  most  quickly  by 
inexperienced  Ada  programmers  are  those  that  are  basically 
Pascal  language  commands  with  a  slightly  different  syntax.  The 
kind  of  commands  needed  to  interface  with  prototype  hardware, 
however,  are  not  of  this  variety,  and  can  be  a  major  source  of 
problems  to  inexperienced  Ada  programmers. 

10. 21. 16  Personnel  Resources 

One  of  the  hardest  things  to  do  for  a  software  project  leader 
is  to  staff  the  job  with  the  right  number  of  designers  at  each 
Phase  of  the  development  cycle.  This  is  true  for  any  real-time 
project,  especially  where  the  software  is  fairly  complex.  The 
lack  of  a  good  supply  of  experienced  Ada  programmers  who  can  be 
quickly  brought  in  can  make  this  staffing  problem  one  of  the 
most  difficult  tasks  on  the  program. 

10.  21.  17  Cost 

It  stands  to  reason'  that  designers  experienced  in  the  language 
of  the  application  will  be,  in  general,  more  productive.  This 
is  especially  true  of  Ada,  where  the  complexity  leads  to  rich 
rewards  when  properly  used.  The  lack  of  a  good  base  of 
experienced  Ada  programmers  means  not  only  that  these  benefits 
will  be  largely  unattainable  for  some  period  of  time,  but  also 
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that  costs  rr.usc  be  incurred  fcTr  training  in  order  to  ever 
realize  these  potential  savings. 

Worse  yet,  mistakes  due  to  inexperience  in  Ada  can  be  made  in 
the  early  phases  [Problem  #21  Software  Requirements  Analysis) 
that  can  increase  costs  by  a  factor  of  two  or  more  if  not 
caught  quickly  enough. 

10.  21.  13  Schedule 

Whenever  costs  rise  unexpectedly,  schedule  problems  naturally 
follow  because  staffing  requirements  go  up  unexpectedly.  If  Ada 
inexperience  can  cause  cost  proclems,  then  it  also  can  surely 
make  solution  of  tnem  very  painful:  where  do  you  find  the 
experienced  Ada  programmers  you  need  to  increase  your  staff? 
And  what  happens  to  your  schedule  if  you  have  to  hire 
inexperienced  people  and  stop  to  tr  A.  them? 

10. 21. 19  Customer  Ralaticns 

•^s  noted'  in  the  Problem  Definition,  the  lack  of  experienced  Ada 
programmers  is  especially  severe  in  the  management  ranks.  Since 
the  procuring  agency  must  assign  a  manager  to  interface  with 
the  applications  software  organization,  it  follows  that  the 
agency  will  have  difficulty  finding  a  good  manager  who  also 
happens  to  know  Ada. 

Customer  relations  are  bast  when  there  is  open  communication 
between  the  agency  and  its  contractors,  and  there  can  be  little 
ccm.mun  ica  ti  on  tf  tne  rigar.cy  manager  doesn't  understand  the  Ada 
prcbls.ms  being  faced. 

10.  21.  20  Stability 

As  noted  previously  (Problem  #21,  Software  Requirements 
Analysis],  the  lack  of  an  experienced  Ada  cadre  will  probably 
lead  to  poor  astimates  of  the  embedded  computer  resources 
needed  to  ?e’!Scorra  software  functions  in  Ada.  When  this  is 
realized  in  latar  design  phases,  changing  the  requirements  is 
one  of  the  few  options  available  that  are  powerful  enough  to 
address  the  serious  problems  that  result. 

The  instability  in  requirements,  both  for  hardware  and  for 
software,  is  the  direct  result  of  the  lack  of  experienced  Ada 
designers  in  t.ne  early  phases,  evan  though  this  may  be  hard  to 
recognize.  3y  the  time  the  problem  is  manifested,  the  staff  has 
probably  gotten  fairly  good  with  Ada,  so  that  is  not  the  first 
problem  you  might  c-bink  of  when  someone  asks,  "Where  did  we  go 
so  wrong?" 
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10.22  EXTENSIVE  ADA  TRAINING  REQUIREMENTS 

The  complexity  of  the  Ada  programming  language  and  the  system 
development  and  run-time  environments  results  in  extensive 
training  requirements  for  Ada  applications  programmers. 

To  fully  prepare  the  applications  to  develop  Ada  software  a 
variety  of  training  should  be  provided  at  different  levels 
throughout  the  various  phases  of  the  project.  Training  should 
be  provided  at  a  minimum  at  the  following  levels  -  Senior 
Technical  Staff,  Junior  Technical  Staff,  and  Management. 

The  training  courses  to  be  offered  should  be  selected  according 
to  the  type  and  level  of  personnel  being  trained.  The 
technical  staff  members  should  be  offered  all  or  some  of  the 
following  courses: 

*  Ada  Language  Overview 

*  Advanced  Ada  Language  Issues 
'*  Ada  Development  Methodologies 

*  Ada  Implementation  Issues 

*  Ada  APSE  Issues 

The  management  staff  should  be  offered  the  following  courses: 

*  Ada  Language  Overview 

*  Ada  Cost/Schedule  Estimation  and  Tracking 

*  Ada  Development  Environment 

*  Ada  Productivity  Issues 

Ada  training  costs  are  high  and  a  large  amount  of  time  is 
required  to  train  the  programmers.  From  3-12  weeks  should  be 
allotted  for  the  technical  staff  and  from  1-3  weeks  for  the 
management  staff.  The  training  courses  should  be  scheduled  to 
coincide  with  the  proposed  project  staffing  plan.  It  should  be 
noted  that  it  is  more  difficult  to  retrain  non-Ada  programmers 
than  to  train  new  programmers. 

10.  22. 1  Training 

One  of  the  major  issues  to  be  considered  in  the  development  of 
real-time  embedded  Ada  applications  is  the  extensive  amount  of 
Ada  training  that  is  required  for  project  personnel.  This  is 
due  to  the  following  reasons: 

*  Complexity  of  the  Ada  programming  lemguage  and  run-time 
environment 

*  Current  immaturity  of  the  available  Ada  tools 

*  The  extensive  system  optimization  required  to  develop  a 
real-time,  embedded  Ada  application 

*  The  current  shortage  of  experienced  Ada  programmers 
(those  who  have  actually  developed  Ada  applications) 
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The  requited  Ada  training  must-  be  provided  to  variety  of 
project  personnel  to  include  senior  technical  staff,  junior 
technical  staff,  and  management.  Different  courses  must  be 
provided  to  the  different  project  personnel  to  correspond  to 
their  experience  levels  and  project  responsibilities.  The 
training  plans  should  also  reflect  the  proposed  staffing  plan 
and  project  personnel  experience  profile. 

The  training  should  a?.3Q  reflect  the  major  software  engineering 
issues  for  the  particular  application  being  developed.  It  is 
important  to  include  courses  which  address  Ada  development 
methodologies  (using  Ad  a  as  it  was  meant  to  be  used), 
implementation  issues,  and  real-world  issues 
!pr obi ems/solu  tions) . 

10.  22.  2  Cost 

The  extensive  training  required  for  Ada  projects  can 
significantly  increase  the  system  development  cost.  This  is 
due  to  the  requirement  to  provide  a  number  of  different  courses 
(language  issues,  implementation  issues,  methodologies, 
cost/schedule  tracking,  etc..}  for  a  variety  of  levels  of 
project  personnel  (senior  technical  staff,  junior  technical 
staff,  management).  These  courses  are  generally  expensive  and, 
depending  on  the  project  staffing  plans,  must  sometimes  be 
given  a  number  of  times  to  coincide  with  each  influx  of  new 
people  on  the  project. 

IG.  22.  3  Schedule 

The  axtansiva  training  requirements  for  Ada  projects  can 
sometimes  have  an  impact  on  the  project  development  schedule. 
This  is  due  to  the  number  of  courses  that  must  be  offered,  the 
length  of  the  courses,  and  the  number  of  times  that  the  courses 
must  be  offered  (to  coincide  with  each  influx  of  new  people  on 
the  project).  To  minimise  the  potential  schedule  impact  of 
this  training,  the  required  training  time  should  be  included  in 
the  project  schedule  estimates. 
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10.  23  INACCORACT  OF  C/S  ESTIMATE  FOR  ADA  PROGRAM 

Most  of  the  Ada  problems  recounted  here  cause  cost/schedule 
perturbations  for  embedded  mission-critical  applications 
[Problems  #1,  3,  4,  5,  6, 7,  8,  9,10,11,13,14,15,16,  17,18,  19,20,  21,22, 
23,  24,  25,  26]. 

Because  of  the  pervasiveness  of  the  influence  of  almost  every 
problem  on  cost  and  schedule  performance,  the  task  of 
estimating  cost  and  schedule  performance  becomes  even  more 
complicated.  Not  only  must  you  understand  enough  about 
software  cost/schedule  estimating,  but  you  must  also  understand 
enough  about  the  additional  problems  you  get  in  Ada.  This  Ada 
problem  knowledge  is  a  very  rare  commodity  today,  which  is  one 
of  the  reasons  this  report  is  being  written. 

In  an  effort  to  help,  there  have  been  extensions  to  one  of  the 
most  popular  cost  models,  COCOMO  [Ref  1] ,  that  attempt  to 
accou!}t  for  some  of  the  better-known  Ada  problems  [Ref  2]. 
These  include  the  instability  of  the  compiler  (major  revisions 
every  six  months  being  the  present  norm)  and  the  extra  time  it 
takes  to  train  Ada  programmers. 

Even  someone  who  has  lived  through  the  Ada  problems  might  be 
hard-pressed  to  estimate  their  cost/schedule  effects  on  a  new 
project.  The  only  real  way  to  do  this  is  to  have  someone  in 
control  of  the  project  who  understands  the  pitfalls  well  enough 
to  avoid  them,  making  their  cost/schedule  effects  near  zero 
(since  avoidance  costs  are  usually  small). 

But  not  all  Ada-specific  cost/schedule  factors  can  be  called 
problems.  After  all,  the  ultimate  reason  to  use  Ada  is  to  save 
money,  not  to  lose  it.  When  a  steady-state  condition  is 
reached  after  a  few  years  of  using  Ada,  developers  should  find 
the  costs  much  improved.  But  again,  since  very  few  have  reached 
this  state,  the  actual  gains  are  very  difficult  to  estimate. 

But  even  when  all  Ada-specific  cost/schedule  influences  can  be 
accounted  for,  which  may  be  years  in  the  future  for  many 
applications  developers,  the  job  of  software  cost/schedule 
estimating  is  anything  but  easy.  This  is  a  long-standing 
software  engineering  problem,  with  even  estimation  models  with 
many  years  of  good  service  being  criticized  for  making  errors 
of  100  percent  or  more  [Ref  3}.  In  fact,  some  recommend 
collecting  your  own  statistics  for  several  project  done  using 
your  own  programming  support  environment  rather  than  using  the 
factors  in  the  models  [Ref  4].  Published  model  factors  are 
based  on  data  from  hundreds  of  projects,  but  if  your 
environment  is  significantly  different  than  the  industry  norm 
then  your  responsiveness  to  these  factors  may  indeed  be  unique. 


RiAL-riMS  ADA  ?R03L£14  STUDY 


10/  9/  87 


[Ref  1]  3. 3oeh*T.,  "Software  Yngirneecing  Economics",  Prentice* 

Kali,  Englewood  Cliffs,  MJ,  1981 

[Ref  2J  R.  w.  Jansen,  "Projected  Productivity  Impact  of  Near* 
Terra  Ada  Use  in  Software  System  Development,  "Hughes  Aircraft 
Co.,  Fullerton,  CA  1985 

[Ref  3]  C. Ramerer, "An  Empirical  Validation  of  Software  Cost 
Es :: t’.nc  .'Jcdais",  Ccmnunications  of  ohe  ACM,  May  1937 

[Ref  ;]  .D  Davis,  ''LMaasuring  the  Programmer's  Productivity", 
Engineering  Manager,  Faoruary  35 

10.23.1  Risk 

The  inability  to  accurately  estimate  the  cost/schedule 
r ecu iremen ts  of  an  embedded  Ada  application  significantly 
increases  the  technical  risk  that  the  job  may  never  be  finished 
at  ail.  This  occurs  when  the  job  is  grossly  underbid,  even  in 
a  cost-p'ius  environment  (in  fixed-price,  the  job  will  probably 
be  aborted  as  soon  as  the  problem  is  realized). 

The  first  response  of  most  developers  to  an  underbid  job  is  to 
respond  in  ways  that  at  least  offer  a  possibility  of 
maintaining  schedule  commitments.  This  may  include 
subcontracting  modules,  hiring  job-shoppers  to  work  in-house, 
and  tryi.ng  to  add  more  hours  from  the  dedicated  project  staff 
(through  hiring  and  ovartirae). 

Doing  any  or  all  of  these  things  makes  project  communication 
vary  difficult.  In  the  absence  of  a  strongly  disciplined 
devalcpraanc  methodology  which  all  but  forces  this 
communication,  it  probably  just  won't  happen.  Unfortunately, 
anything  that  has  the  appearance  of  a  non-crisis  task  tends  to 
get  buried  in  the  panic  environment  of  a  badly  underbid 
project,  and  methodology  requirements  are  definitely  non¬ 
crisis. 

Without  good  communication  the  chances  of  a  complex  project 
ever  completing  are  not  good.  If  it  does  complete,  it  will 
probably  need  an  "update"  immediately,  where  update  is  a 
for  "start  over  and  do  it  right  this  time.  " 

IG. 23. 2  Rsrsonnel  Resources 

The  inability  to  estimate  cost/schedule  requirements  accurately 
will  impact  personnel  resources  first.  Sonicraft,  working  on 
the  ME£C^7  project,  found  just  after  the  Preliminary  Design 
Review  rhar  the  staff  needed  to  quadruple  to  meet  the  Critical 
Design  Review  date.  A  combination  of  temporary  help  (job- 
shoppers)  ,  hiring  and  heavy  overtime  for  six  months  brought  in 
the  detail  design  acceptably  close  to  the  original  date.  While 
this  prevented  a  quick  cancellation  of  the  job,  it  by  no  means 
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solved  the  staffing  probles.  which  continued  in  one  forn  or 
another  for  two  more  years,  mostly  due  to  the  inability  to 
forecast  accurately. 

10. 23. 3  Facilities 

Closely  related  to  cost/schedule  forecasts  are  the  facilities 
needed  to  support  the  development  staff.  Onderestimating  the 
staff  needs  can  be  partially  compensated  by  adding  facilities 
that  boost  productivity,  and  many  companies  use  this  tactic 
(along  with  others  in  parallel}.-  The  reason  that  this  is  a 
problem  is  that  the  productivity  gains  rarely  justify  the  cost 
of  such  emergency  purchases,  and  facility  work  on  other 
projects  with  higher  savings  must  be  postponed. 

If  forecasts  are  really  far  off  (and  that  is  not  at  all 
uncommon),  the  added  staff  may  find  present  facilities 
inadequate.  Contention  for  available  host  computer  time,  for 
breadboard  test  time,  and  even  for  open  host  computer  terminals 
may  slow  down  the  project  to  the  point  where  the  added  staff 
has  little  effect. 

10. 23. 4  Customer  Relations 

The  inaccuracy  of  Ada  cost/schedule  estimations  can  be  counted 
on  to  erode  whatever  good  relations  were  previously  enjoyed 
with  the  customer.  No  customer  li)(es  dealing  with  a  contractor 
who  regularly  produces  unpleasant  surprises  affecting  the  cost, 
the  delivery  date,  and  (when  desperate}  the  specifications  of 
the  delivered  system. 

10. 23. 5  Stability 

The  inability  to  estimate  Ada  cost  and  schedule  leads  to  many 
short-term  responses  which  attempt  to  minimize  schedule 
slippage.  As  schedules  are  seen  to  start  slipping  anyway,  and 
as  costs  start  to  climb  alarmingly,  any  good  manager  will  look 
to  the  only  relief  in  sight:  the  specifications. 

In  any  system  there  are  *nice-to-have”  functions  which  become 
the  focus  of  intense  negotiations  when  a  project  is  in  trouble. 
Since  the  contracting  agency  doesn't  want  to  see  the  project 
fail,  this  usually  results  in  some  contract  reinterpretations 
or  modifications  that  give  some  relief  to  the  contractor. 

When  it  happens,  the  unfortunate  result  of  this  is  an 
instability  of  the  specifications  that  affects  not  only  the  two 
parties  directly  involved  but  also  many  support  organizations 
and,  eventually,  the  using  and  maintaining  organizations. 
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10.  24  L-'.C:;  ZiTA-SLlSaZID  AjIA  SaFTHAHi:  DfiVSLOPriENT  METHODOI/OGY 

One  of  t.;i2  .T.cst.  ir.pcrtant  features  of  Ada  is  that  it  encourages 
the  use  of  ir.odarn  software  engineering'  development  practices 
[Problem  #21].  These  practices  can  best  be  exploited  when  they, 
are  packaged  within  a  good  development  methodology.  The  lack  of 
an  established  Ada  development  methodology  can  be  a  problem  in 
that  engineers  trained  in  one  methodology  are  less  mobile  if 

other  org.-iniu  rti  er.n  'ever,  within  the  same  patent  organization) 
use  a  difiere.v'.  me.  i'his  in  turn  contributes  to  the  lack  of 
experiencao  .-.a u  u r ogr a;r.mer 3  [Prcolem  #21]  since  an  important 
part  c:;  -.hsir  .'•up  iar.ce  is  their  methodology  training. 

This  r  i  re  :  s  .2  y  chat  there  is  a  lack  of  good  Ada 

methcdc.ogi  es.  .'in  fact  thera  ar-a  two  very  good  ones,  Object 
Orier.tec  resign  (OOD)  and  PA..-i£LA  (TM  George  Cherry).  One  of 
these,  OCD,  i3  gaining  both  popularity  and  respect  very 
rapicly,  crd  ?.\M£LA,  while  held  back  now  by  limitations 
dascricrc  re.cv,-  has  good  long-term  potential  also. 

COD  IS  .>r --U  a:  c  car  upon  the  premise  that  problem  definition  is 
the  f  i  ;  :  and  h  a  r  ■f  a  s  t  z  as':  e  designer  confronts,  OOD 

CO  near,  truce  3  on.  he  icing  the  designer  with  this  task  by 
stripping  aw-ey  much  of  the  syntactic  material  that  adds  little 
to  this  task.  It  does  this  by  defining  the  Object  as  an  Ada 

package  or  cask,  which  is  a  higher  level  view  than  the  module 

of  Yourdan  [Aef  1].  This  ha.s  lad  .some  to  proclaim  OOD  as  being 
the  met;  promc-sing  of  the  "technical  fads*  now  available  to 
i.T.prova  -or  ucr  a.r..mar  'prcduc  tivi  cy  (Aef  2].  But  it  also  causes 
sCiZ-j  ; o.',:.3 i  ui .1  -.hr :  OCD  io  too  limitad  when  it  comes  to 
express  en.r  rn  t  r.y  n.c..mi.s.t  of  .Ida  .sys'tems  in  operation  [Ref  1]. 

?A.'4£LA,  on  the  other  hand,  is  best  at  describing  the  dynamism 
of  .^da  systems.  It  is  the  fir'St  process-flow  methodology 
spec  iflca''.’y  adapted  to  the  Ada  syntax  [Ref  1],  using  easy  to 
learn  grap.oicai  technicuas  to  input  the  design  information  that 
it  .^ill  :.;.32  :o  genera ta  code  automatically.  This  labor-saving 
step  is  also  its  biggest  problem  right  now,  however,  since  it 
ganerate-j  an  .Ad.-?,  task  for  every  ’’single-thread"  (no  children) 
proces.:  [.Ref  Ij  .  With  current  Ada  compilsrs  the  overhead  due  to 
context  switching  is  Zee  high  to  .allow  free  use  of  tasking. 

Senior  eft.  In  the  system  development  .in  Ada,  was  forced 

to  redesign  extan-sively  to  cut  down  the  number  of  tasks  in  the 
syste.m  because  it  could  not  meet  the  design  constraints.  Even 
the  -felivired  design,  .vith  only  ten  tasks,  was  a  problem 
because  30.ta  vers  nastad  as  .much  as  three  levels  deep,  causing 
very  high  avsrZ:sed  -vith  tha  compiler  than  in  use.  This  is  the 
other  oojecri'.n  to  .-.'-Jr’ZLA;  it  laads  to  dseply-nested  structures 
[Ref  li. 

Mota  that  neither  of  the  t-wo  limitations  to  the  use  of  PAMELA 
ars  necessarily  1  ong-las'ting  ones.  When  Ada  compilers  become 
evailsoie  that  can  do  vary  rapid  context  switches  (perhaps  in 
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conjunction  with  underlying  microprocessors  that  have  richer 
instruction  sets)  and  that  maintain  a  single  task  stack  for  the 
parent  task  and  all  direct  descendants  (to  avoid  context 
switches  among  them) ,  PAMELA  may  become  much  more  widely  used. 

As  a  final  note,  there  are  some  software  organizations  that 
service  customers  outside  the  Department  of  Defense  and  thus 
may  need  to  use  languages  other  than  Ada  on  some  projects. 
Sonicraft/  for  example,  is  currently  involved  in  the  FAA's 
Airport  Modernization  Program,  and  was  specifically  directed  to 
use  the  same  language  as  the  Principal  Contractor,  which 
happened  to  be  "C.  *  Since  one  of  the  main  goals  of  a 
functional  software  organization  is  the  balancing  of  labor 
resources  between  on-going  and  planned  projects,  the  use  of  a 
non- language-specific  methodology  was  preferred.  This  allowed 
programmers  to  be  m'oved  between  the  two  major  projects  to 
satisfy  special  project  needs  or  to  further  individual  career 
goals.  Had  Sonicraft  faced  major  retraining  costs,  because  the 
methodology  was  changed  as  well  as  the  language,  such  moves 
would  have  been  far  less  frequent. 

[Ref  1}  S.  Boyd, "Ada  Methods:  Object-Oriented  Design  t  PAMELA*, 
SlGAda,  Nov  86 

[Ref  2)  F.  P.  Brooks, "No  Silver  Bullet",  IEEE  Computer,  Apr  87 


10.  24.  1  Method  Type 

The  lack  of  an  established  Ada  software  development  methodology 
makes  it  harder  to  decide  which  one  to  use  on  a  specific 
project.  There  had  been  a  similar  problem  with  software  written 
in  other  languages  until  the  Yourdan  methodology  of  Structured 
Analysis  and  Structured  Design  "became  pervasive  within  the 
software  engineering  community"  [Ref].  The  dangers  inherent  in 
picking  a  methodology  that  turns  out  to  be  off  the  mainstream 
of  the  community  include: 

*  Extensive  retraining  will  be  needed  for  new  hires,  who 
will  be  unlikely  to  know  your  methodology 

"  Communication  with  other  projects  in  Ada  will  be 
crippled  because  you  will  probably  use  terms  like 
"module”  to  mean  something  different  than  they  might 
define  them  to  mean 

*  Performance  may  be  hard  to  relate  to  industry  norms 

because  you  might  be  measuring  different  things  within 
your  methodology,  or  you  may  have  an  inappropriate  set 
of  tools  to  measure  what  others  do 

[Ref]  S.  E.  Watson,  "Ada  Modules",  Ada  Letters,  vii.  4-7  9,  1987 
10. 24. 2  Personnel  Resoures 
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The  Lack  of  an  asoablished  Ada  software  development  methodology 
makes  tha  Ada  dasignars  less  mobile  between  projects  or 
organizations.  Whan  extensive  methodology  training  is  required 
to  introduce  new  membars  to  a  team,  the  project  leaders  tend  to 
exhaust  ocher  possibilities  first,  such  as  massive  overtime. 

10.24.3  Pacilities 

Mathodoiog ias  tend  to  hava  standard  tools  and  facilities  that 
maka  chair  use  more  afficient-  If  a  standard  Ada  methodology 
ware  co  amargs,  so  tnat  managers  knew  that  any  investment  in 
thasa  cools  would  also  pay  off  for  future  projects,  they  would 
ba  nor  a  v.'iliir.g  to  buy  them. 

This  willingness  to  purchase  the  tools  would  help  create  a  mass 
market  for  them,  driving  down  the  price  and  improving  both  the 
quality  and  tha  features  as  more  vendors  were  attracted  to 
serve  the  burgeoning  market. 

10.  24.  4  Ccst 

Tha  costs  associated  with  the  lack  of  an  established  Ada 
mechodolocy  are  chcsa  which  are  incurred  when  someone  already 
trained  in  one  methodology  must  be  retrained  in  another.  These 
costs  would  be  reduced  if  most  projects  used  the  same  or  very 
similar  machodologias. 

10.  2-i.  S  Schedule 

The  schedala  delays  which  occur  due  to  the  lack  of  an 
eataoiishad  Ada  mschodology  are  those  incurred  due  to  the 
linger,  of  cha  craini.Tg  ti.me  when  adding  new  staff.  Instead  of 
being  procuctive  in  a  Sew  weeks,  whan  the  basics  of  Ada  syntax 
and  the  basic  cools  on  the  host  computer  have  been  learned,  the 
new  designer  requires  additional  weeks  or  months  to  get 
comfortable  with  tha  methodology  being  used. 

An  established  methodology  would  reduce  these  delays  by 
increasing  the  ,cr.ci’ ity  that  the  new  designer  already  knows 
the  methodology  being  used. 

1C.  2  4.  5  Ii3t.l:sation 

The  usual  problems  in  esti.Tiating  a  software  job  are  compounded 
if  there  is  no  established  Ada  methodology.  Since  planning 
mistakes  are  usually  rectified  by  adding  new  staff  (assuming 
t.he  project  duration  is  long  enough  to  tolerate  thisi  ,  anything 
which  increases  the  cost  of  adding  staff  will  have  a  Leveraging 
effect  on  cost  estimates,  making  even  relatively  small  errors 
more  expensive  to  correct  (both  in  cost  and  in  schedule 
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Customer  relations  cam  suffer  from  the  lack  of  an  established 
Ada  design  methodology  in  two  ways.  First,  and  most  important, 
the  customer  may  be  unfamiliar  with  the  methodology  being 
employed.  This  hurts  the  needed  communications  since  output  and 
progress  may  be  measured  in  ways  the  customer  does  not  fully 
understand.  If  the  customer  has  monitored  other  projects  that 
have  used  the  contractor  methodology,  the  relationship  becomes 
more  comfortable. 

The  second  problem  is  that  it  becomes  a  little  more  expensive 
to  do  things  if  there  is  no  establishe'd  methodology.  Project 
cost  and  schedule  can  increase  [Problem  #24  Cost,  Schedule], 
and  it  also  takes  more  effort  for  the  customer  to  learn 
effective  ways  to  monitor  the  work. 

10.  24.  8  Stability 

In  extreme  cases  a  project  can  be  subjected  to  massive  cost  and 
schedule  overruns.  If  the  product  is  deemed  valuable  enough, 
the  project  may  be  allowed  to  continue,  which  then  makes  the 
lack  of  a  standard  Ada  design  methodology  important.  By  raising 
the  cost  of  training  the  additional  staff  needed  to  recover, 
plus  extending  the  time  needed  for  them  to  become  trained 
enough  to  contribute,  this  problem  could  force  both  the 
customer  and  the  contractor  to  look  for  ways  to  down-scope  the 
product  specifications. 

The  resulting  instability  in  what  the  product  is  expected  to  be 
will  cause  a  whole  new  set  of  problems. 
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10. 25  LACS  OF  ESTABLISHED  ADA  SOFTWARE  STANDARDS  AND 
GUIDELINES 

Sonicraft  is  among  the  crowing  number  of  software  development 
organizations  that  measures  the  productivity  of  each  designer 
and  manager,  rewarding  them  primarily  on  this  measured 
productivity  and  the  quality  of  their  software  products.  This 
has  been  proven  over  and  over  to  be  a  sound  practice  since  we 
have  obsarv'id  r.iau  the  differenca  in  productivity  between  the 
hart  and  ch a  'vorst  programmers  to  be  consistently  about  a 
factor  of  tan.  Besides  keeping  turnover  of  the  best  people  very 
lev,  this  policy  also  strongly  encourages  the  worst  to  either 
quickly  improve  or  to  find  another  line  of  work. 

The  reason  all  organizations  don't  use  this  practice  is  that  it 
takes  a  considarabia  amount  of  effort  to  make  it  work  right. 
The  measurands  wa  use  are,  by  now,  quite  standard  (operational 
lines  of  coda  and  hours  charged  to  the  project),  with  good 
tools  avail  able  to  automate  their  collection.  The  hardest  part 
is  to  ■'establish  standards  that  can  be  anchored  in  some  facts, 
sucn  as  the  ubiquitous  "national  average  productivity",  or  a 
baseline  iormec  from  several  similar  projects  done  in  our 
environment  [Ref]. 

Hers  is  the  problem  that  Ada  introduces.  Because  of  the 
difficulties  in  estimating  the  number  of  lines  of  code  or  labor 
hours  t.-Jat  a  project  should  take  (Problem  #23],  the  credibility 
of  the  standard  is  jeopardized.  As  long  as  the  standards  were 
based  on  naasurad  acccmplishments  of  others,  they  were  accepted 
as  c  b;-.a.._snge.  3u:  if  they  must  be  based  on  theory  because 

Ada  has  a  dearth  of  real  data,  their  motivational  value  is 
graatl'y  red'uced. 

Compounding  the  problem  is  the  observation  [Problem  #23]  that 
the  productivity  of  Ada  programmers  is  likely  to  start  out 
■^orsa  than  with  other  languages,  then  rapidly  improve,  ending 
up  witn  higher  productivity  than  other  common  languages.  This 
makes  productivity  data  collection  far  more  difficult,  since  it 
is  continually  changing  over  a  period  of  two  or  three  years.  It 
also  makss  tha  data  from  other  organizations  more  suspect  since 
it  is  hard  to  tell  sxactly  where  on  the  learning  curve  they 
might  be  operating. 

■Ref]  H.  Davis,  ".Measur  ing  the  Programmer's  Productivity", 
Engineering  Manager,  February  35 

12.  25.  1  Parsonr.al  Resources 

The  lack  of  established  .\da  productivity  standards  can  cause 
highar  turnovar  among  the  most  productive  people.  These  people 
can  no  longer  be  rewarded  as  well  whan  the  standards  are 
uncertain  or  poorly  defined.  Similarly,  the  least  productive 
people  will  be  less  inclined  to  improve,  preferring  to  blame 
their  troubles  on  the  questionable  measurement  standards. 
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The  net  effect  of  these  two  tendencies  is  an  overall  lowering 
of  the  project  team  productivity.  This  strains  the  available 
personnel  resources  in  support  of  the  project,  which,  because 
of  other  problems  [such  as.  Problem  #21]  may  be  difficult  to 
replenish. 

This  effect  can  be  startling  in  its  magnitude  when  seen  in 
action  on  two  apparently  similar  projects,  the  main  difference 
being  the  use  or  non-use  of  productivity  standards.  It  is 
possible  to  see  the  project  using  the  standards  operate  at 
double  the  national  average  productivity  while  the  non-user 
operates  at  half. 

10.  25.  2  Cost 

Due  to  the  combined  effects  of  losing  more  of  the  most 
productive  designers  and  being  saddled  with  non- improving  poor 
performers  [Problem  #25  Definition],  the  unavailability  of 
established  Ada  productivity  standards  can  drive  up  project 
costs  very  substantially. 

Disturbingly,  the  process  doesn't  take  long  once  it  is  set  in 
motion.  A  project  can  get  a  reputation  as  being  ”a  bunch  of 
losers"  after  only  a  year  or  two,  which  will  hasten  the 
departure  of  the  best  people  still  remaining. 

10.  25.  3  Schedule 

The  combination  of  rising  amounts  of  labor  needed  to  do  each 
task  [Problem  #25  Cost]  plus  the  difficulty  of  replenishing  the 
availeible  labor  base  in  support  of  the  project  [Problem  .#21 
Personnel  Resources]  can  lead  to  missed  deadlines. 

10.  25.  4  EstisMtion 

The  lack  of  established  Ada  productivity  standards  can  increase 
the  turnover  of  the  most  productive  designers  on  the  team 
[Problem  #25  Cost].  Since  these  are  the  people  who  get  most  of 
the  work  done,  the  increased  risk  of  losing  them  makes  the 
estimation  process  even  more  difficult. 

The  reverse  problem  also  occurs.  The  lack  of  established  Ada 
productivity  standards  can  decrease  the  rate  of  improvement  or 
elimination  of  the  least  productive  designers.  Carrying  a  poor 
performer  not  only  increases  cost  but  makes  it  more  difficult 
to  add  a  more  productive  person  to  the  team.  This  also  makes 
the  process  of  estimation  more  difficult  by  weakening  one  of 
the  main  sources  of  management  control:  when  things  start  going 
poorly  they  can  deteriorate  very  quickly,  and  a  rapidly- 
changing  process  is  almost  impossible  to  estimate. 
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10.  26  PRODUCTIVITY  IMPACTS  OF  ADA 

Of  the  preceding  25  problems,  18  have  been  shown  to  influence 
the  cost  of  an  embedded  Ada  system.  On  the  other  hand  it  is 
often  true  that  problem  identification  is  the  hardest  part: 
once  you  know  what  the  problem  is,  the  solution  is  sometimes 
obvious.  This  report  is  ^erefore  not  as  discouraging  as  it  may 
seem  at  first  reading. 

In  the  case  of  Ada,  there  eire  some  long-term  cost  benefits  that 
are  the  ultimate  reason.it  has  been  adopted  as  the  standard 
language  for  Department  of  Defense  embedded  mission-critical 
software  [Ref  1].  And  other  Languages  are  not  problem-free: 
MGEN  Smith  reported  that  70  to  80  percent  of  the  late  Air  Force 
projects  are  having  software  problems  [Ref.  2].  At  the  same 
conference  MGEN  Salisbury  reported  another  need  for  a  standard 
language  like  Ada  that  can  handle  a  wide  variety  of 
applications:  The  Standard  Army  Management  Information  System 
(STAMISJ  had  grown  to  750  systems,  now  reduced  to  110.  Using 
Ada  is^  expected  to  cut  it  to  37  programs. 

The  one  area  which  is  probably  the  biggest  source  of  Ada 
productivity  problems  is  the  speed  of  the  compiler.  Compilation 
speeds  have  been  steadily  dropping  for  VAX-host,  Intel-target 
compilers.  Sonicraft  has  seen  a  times  ten  improvement  here  in 
the  last  two  years,  with  another  big  improvement  reported  to  be 
in  the  offing  for  a  compiler  to  be  validated  in  September  1987 
[Ref  31. 

For  the  present,  however,  Ada  does  have  serious  productivity 
impacts  which  can  price  it  out  of  the  market  for  many  projects 
IF  YOU  LOOK  AT  DEVELOPMENT  COSTS  ONLY. 

[Ref  11  Department  of  Defense  Directive,  3405.  2,  Subject:  Use 
of  Ada  in  Weapon  Systems,  Mar  87 

[Ref  2]  Policy  Committee  Reports  Prom  Armed  Services,  SIG  Ada, 
Nov  86 

[Ref  3}  L.  Silver  thorn,  DDC-I,  Phoenix,  AZ 


10.  26.  1  Debugger 

The  debugger  currently  available  for  the  Intel  microprocessors 
was  derived  from  the  Intel  Pascal  debugger  and  cannot  follow 
the  context  switches  of  Ada  tasks  (since  nothing  comparable 
exists  in  Pascal). 

Debugging  within  the  scope  of  a  single  task  does  not  sound 
overly  restrictive,  but  many  of  the  most  difficult  code 
problems  involve  interrupts  whose  handlers  are  implemented  as 
tasks.  This  limitation  can  seriously  impact  productivity  during 
the  Code  and  Test  Phase  and  the  CSC  Test  Phase. 


REAL-TIME  ADA  PROBLEM  STODY 


10/  9/  87 


10. 26. 2  POL  Pcocessor 

There  have  been  a  number  of  improvements  since  Sonicraft  wrote 
its  original  MEECN  Project  CPCI  Product  Specification  (C5)  in 
1983  and  early  1984.  The  POL  processor  used  was  incapable  of 
compiling  the  Program  Design  Language  (POL),  which  caused 
severe  rework  problems  that  could  have  been  largely  avoided. 

The  current  POL  processors  are  still  being  actively  developed, 
and  the  discussion  continues  as  to  exactly  what  functions  a  POL 
processor  should  support.  When  standardization  occurs  the 
productivity  on  Ada  work  will  rise  somewhat,  although  this  is 
no  longer  the  problem  it  once  was. 

The  directive  mandating  the  use  of  Ada  [Ref]  does  encourage  the 
use  of  compilable  POL,  which  is  the  right  way  to  go  in 
Sonicraft* s  experience. 

[Ref]  OoD  Directive  3  405.  2,  *0se  of  Ada  in  Weapon  Systems,” 
March  87 

10.  26.  3  Coiqpiler 

The  Ada  compiler,  despite  tremendous  improvements  in  the  past 
few  years  [Problem  #26  Definition],  is  still  the  source  of  much 
of  the  lost  productivity  faced  by  an  embedded  Ada  software 
developer.  When  you  can  read  about  a  *C”  compiler  that  is 
advertised  [Ref]  to  run  about  a  hundred  times  as  fast  on  a 
plain-vanilla  Personal  Computer  clone  as  the  best  Ada  compiler 
can  run  on  a  VAX,  you  know  there  is  room  for  improvement  here. 
To  be  fair,  the  Ada  compiler  does  much  more  than  any  *C” 
compiler,  but  the  difference  should  not  be  a  factor  of  a  ten  to 
hundred  when  far  less  computer  resources  are  available  to  it. 

[Ref]  Turbo  "C*  advertisements  for  10,000  lines  of  code  per 
minute  compile  speed 

10. 26. 4  Personnel  Resources 

With  personnel  resources  already  stretched  thin  by  the  lack  of 
experienced  Ada  programmers  [Problem  #21],  the  poor 
productivity  of  Ada  tools  can  really  hurt  a  project,  especially 
if  it  comes  as  a  surprise. 

10. 26. 5  Facilities 

At  one  point  in  the  MEECN  Project  development,  Sonicraft 
seriously  considered  the  purchase  of  a  "RAM  Disk”  to  improve 
the  then  unacceptably  slow  speeds  which  were  available  for  vax- 
host,  Intel-target  cross-  compilations.  Fortunately  an 
appreciably-faster  compiler  was  released  before  this  commitment 
was  made. 
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For  some  projects,  in  other  circumstances,  decisions  to  upgrade 
facilities  to  compensate  for  poor  Ada  tool  productivities  may 
be  required. 

10. 26. 6  Cost 

Cost  is  directly  dependent  on  productivity,  so  low  productivity 
Ada  tools  will  increase  Ada  software  development  costs. 

10.26.7  Schedule 

Schedule  problems  could  arise  from  the  poor  productivity  of  Ada 
tools  only  if  they  are  unanticipated.  This  is  very  possible, 
since  the  benchmarking  software  for  these  tools  is  still 
inadequate  [Problem  #17]. 

10.  26.  8  Estimation 

The  low  productivity  of  Ada  tools  makes  the  estimating  task 
more  d'ifficult  simply  because  a  larger  effort  is  required.  When 
the  project  staff  goes  up,  the  interactions  internal  to  the 
staff  as  well  as  those  with  elements  outside  the  project  staff 
get  more  complex. 

A  more  serious  effect  on  estimating,  however,  is  the 
uncertainty  as  to  exactly  how  'Productive  the  Ada  tools  are 
[Problem  #17]. 
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10.  27  IMPACT  OF  CONSTRAINT  CHECKING  ON  SYSTEM  PERFORMANCE 

Ada  provides  the  capability,  within  the  language,  to  perforin 
constraint  checking.  Constraint  checking  provides  the  Ada 
application  developer  with  a  means  to  determine  whether  a 
variable  was  assigned  a  value  at  runtime  that  is  outside  of  its 
defined  range.  When  this  event  occurs,  the  exception 
CONSTRAINT_ERROR  is  raised  to  signal  the  problem.  "However, 
the  event  that  the  reguirements  for  constraint  checking  become 
too  severe,  Ada  provides  a  SUPPRESS  pragma  to  disable  this 
feature.  " 

10.27.1  Efficiency 

The  inclusion  of  constraint  checking  can  adversely  affect  the 
efficiency  of  an  Ada  application.  Bae  overhead  associated  with 
performing  constraint  checking  can  cause  thee  application  to 
use  more  CPU  resources. 

1C.  27.  2  System  Sizing 

The  constraint  checking  code  resides  in  memory  as  part  of  the 
runtime  environment.  Even  if  the  SUPPRESS  pragma  is  used  to 
disable  constraint  checking,  the  unnecessary  code  still  resides 
in  the  runtime  environment.  If  constraint  checking  is  not 
desired  for  an  application.  the  unnecessary  couj.  be  removed 
from  the  runtime. 

10.  27.  3  System  Timing 

An  application  which  performs  a  large  amount  of  constraint 
checking  could  experience  a  significant  increase  in  system 
timing  overhead.  This  overhead  is  in  addition  to  the  normal 
range  checking  that  is  performed  by  a  developer  within  the 
application  program  itself. 
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10.28  INABILITY  TO  ASSIGN  DYNAMIC  TASK  PRIORITIES 

"Ada  does  support  a  capability  for  dynaaically  altering  the 
priority  of  a  currently  running  task.  The  value  for  the  pragma 
PRIORITY  is  static  and  therefore  cannot  be  changed  at  runtime. 
Implementations  may  support  an  alternate  set  of  priorities  that 
control  tasking  in  the  case  where  the  Ada  PRIORITY  is  identical 
or  undefined.  ...  This  allows  an  implementation-defined 
subpriority,  which  may  be  dynamic,  to  control  the  scheduling. 
This  capability  is  not  supported  by  many  implementations,  and  a 
standard  does  not  exist  to  help  provide  commonality.  " 

10.28.1  Coii^lexity 

Because  of  the  inability  to  assign  dynamic  task  priorities 
within  the  Ada  language,  the  developer  must  implement  this 
feature  if  it  is  desired.  The  developer  can  implement  a 
limited  form  of  dynamic  priorities  with  considerable  effort  and 
at  the  cost  of  a  considerable  increase  in  the  complexity  of  the 
application. 

10.  2  E.  2  Portability 

To  implement  the  assignment  of  dynamic  task  priorities,  the 
applications  developer  must  have  knowledge  of  the  dynamic 
defined  subpriority  as  implemented  in  the  version  of  the  Ada 
compiler  that  is  being  used.  Using  this  knowledge,  however, 
reduces  the  portability  of  the  Ada  application  by  building  in 
implementation  dependencies. 
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10.29  INABILITY  TO  PERFORM  PARALLEL  PROCESSING 
10.29.1  Efficiency 

For  those  operations  which  lend  themselves  to  parallel 
processing,  the  efficiency  with  these  operations  are  performed 
could  be  greatly  improved  through  the  use  of  parallel 
processing.  An  example  of  this  type  of  application  would  be 
matrix  arithmetic  operations. 

10.  2  9.  2  Con^lezity 

The  implementation  of  parallel  processing-oriented  operations 
in  a  non-parallel  processing-oriented  environment  can  cause  a 
significant  increase  in  system  complexity.  This  could  involve 
che  use  of  special-purpose  hardware  and  software  to  perform  the 
parallel  processing  operations. 

10.  2  9.  3  Portability 

The  use  of  special-purpose  hardware  and  software  to  implement 
parallel  processing  operations  can  reduce  the  portability  of 
Che  application. 
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10.  30  LACE  OP  SUPPORT  FOR  LOW  LE7EL  OPERATIONS 

”Ada  does  not  provide  a  mechanisa  to  control  the  processor 
state  (including  interrupt  masks  required  for  critical 
sections}.  Although  Ada  provides  a  mechanism  to  directly 
manipulate  memory  mapped  hardware,  no  capability  exists  within 
the  language  to  access  internal  processor  registers.  Such  a 
mechanism  would  be  difficult  to  standardize.  * 

For  example,  "..changing  the  processor  state  needs  to  be  done 
in  conjunction  with  the  runtime.  Since  stacks  used  for 
different  states  are  often  separate,  simply  changing  state  will 
result  in  an  error  condition.  Also,  subsequent  calls  to  the 
runtime  (possibly  due  to  exceptions)  are  likely  to  cause 
unpredictable  results.  ” 

Another  example  is  that  ”. .  there  is  frequently  a  need  to  enable 
and  disable  interrupts  which  is  performed  by  setting  or 
clearing  interrupt  masks.  It  is  easy  for  a  programmer  to  write 
an  assembly  language  routine  to  manipulate  an  interrupt  mask 
and  call  this  routine  from  an  Ada  program.  The  problem  occurs 
because  the  assembly  language  is  not  working  in  conjunction 
with  the  runtime  environment  provided.  " 

10.  30.  1  Complexity 

To  perform  low  level  operations  within  an  Ada  application,  the 
applications  developer  must  try  to  account  for  for  any  possible 
impacts  to  the  RSL.  The  implementation  of  these  operations  can 
significantly  increase  the  complexity  of  the  application. 

10.  30.  2  Reliability 

The  overall  reliability  of  an  Ada  application  can  be  affected 
by  the  potentially  unpredictable  results  that  can  occur  when 
low  level  operations  are  not  implemented  in  conjunction  with 
the  RSL. 

10.  30.  3  Correctness 

The  unpredictable  results  that  can  occur  when  low  level 
operations  are  implemented  can  adversely  impact  system 
correctness  by  making  it  difficult  to  ensure  that  the  system 
performs  as  specified  and  required. 
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10.  31  INABILITY  TO  PERFORM  TASK  RESTART 

Applications  which  require  that  a  separate  thread  of  control 
(task}  be  restarted  at  the  beginning  after  being  interrupted 
part  way  through  have  difficulty  mapping  this  requirement  to 
Ada. 

"Certain  applications  do  have  a  need  to  be  able  to  have 
multiple  tasks,  where  one  task  might  be  pre-empted  by  a  higher 
priority  task,  eind  the  result  of  the  pre-emption  is  to  make  the 
continuation  of  the  pre-empted  task  meaningless.  " 

"The  standard  Ada  solution  to  this  problem  is  to  ABORT  the 
pre-empted  task,  and  then  re-activate  a  new  task.  This  creates 
a  few  undesirable  aide  effects,  not  the  least  of  which  is 
likely  to  be  unacceptable  performance  degradation.  " 

10.31.1  Efficiency 

Performing  a  task  restart  by  aborting  the  pre-empted  task  and 
re-activating  a  new  task  can  adversely  affect  efficiency  by 
causing  performance  degradation.  The  performance  degradation 
results  from  the  overhead  associated  with  task  activation  and 
deactivation. 

10.  31.  2  Reliability 

The  overall  reliability  of  an  Ada  application  can  be  affected 
by  the  potentially  unpredictable  resultr  that  can  occur  when 
aborting  a  task  and  restarting  a  new  task. 

In  the  book  "Software  Engineering  With  Ada",  Grady  Booch  says: 
"This  [aborting  a  task]  has  the  effect  of  prematurely  killing  a 
task  and  all  of  its  dependent  tasks.  This  is  a  rather 
ungraceful  means  of  task  termination  and  should  be  done  only 
when  all  other  means  fail.  " 

The  task  abort  and  restart  are  also  somewhat  non- 
deterministic;  a  task  is  ACTUALLY  started  or  stopped  at  some 
time  after  the  request  is  made.  This  time  interval  depends  on 
the  implementation  of  tasking  in  the  particular  Ada  environment 
being  used. 

10.  31.  3  Correctness 

The  unpredictable  results  that  can  occur  when  tasks  are 
aborted  and  restarted  can  adversely  impact  system  correctness 
by  making  it  difficult  to  ensure  that  the  system  performs  as 
specified  and  required. 


"B  101 


REAL-TIME  ADA  PROBLEM  STODT 


10/  9/  87 


10.32  IHABILXTZ  TO  PERFORM  CYCLIC  SCBEDOLING  IN  ADA 

Cyclic  scheduling  provides  the  capability  to  perforin  periodic 
processing  by  running  a  number  of  processes  on  a  scheduled  time 
basis.  ”The  Ada  language  can  support  some  degree  of  periodic 
processing  by  using  the  DELAY  statement.  Although  some 
implementations  provide  a  reasonable  mechanism  for  this,  the 
DELAY  statement  is  not  always  adequate  for  this  application.  " 

"The  problem  [with  the  DELAY  statement]  is  that  the  duration 
value  is  a  delay  from  the  current  time,  not  a  fixed  interval. 
Therefore,  the  clock  must  be  read  and  the  cycle  computed  in  the 
simple_expression  allowed  for  the  DELAY  statement.  However, 
there  is  no  way  to  ensure  that  an  interrupt  (and  possibly  a 
higher  priority  task)  is  not  executed  between  the  time  the 
clock  is  read  in  the  simple.expression  and  when  the  delay 
duration  is  actually  interpreted  by  the  runtime  [program).  " 

10.  32.  1  Correctness 

The  non-determinism  of  the  Ada  DELAY  statement  in  the 
imolementation  of  a  cyclic  scheduler  has  an  adverse  impact  on 
correctness.  This  is  because  the  applications  developer  cannot 
ensure  that  the  period  that  is  specified  for  running  a  process 
(timeslicing }  is  actually  the  amount  of  time  that  the  process 
runs. 


10.  32.  2  Complexity 

The  difficulty  in  trying  to  implement  an  accurate  cyclic  in  Ada 
using  the  DELAY  statement  can  cause  a  significant  increase  in 
the  complexity  of  the  Ada  application  which  contains  the 
scheduler. 
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10.33  LACE  OF  FLOATING  POINT  COPROCESSOR  SUPPORT 

"A  floating  point  coprocessor  is  a  high  performance  numerics 
processing  element  that  extends  the  main  processor  architecture 
by  adding  significant  numeric  capabilities  and  direct  support 
for  floating  point,  extended  integer,  and  BCD  data  types.  The 
presence  of  a  floating  point  chip  would  increase  performance  in 
a  real-time  embedded  application  that  required  floating  point 
operations  to  be  performed.  * 

"There  is  a  lack  of  a  standard  for  floating  point  coprocessor 
support  in  Ada.  Some  compilers  require  a  floating  point  chip 
to  perform  floating  point  processing;  other  compilers  cannot 
utilize  the  chip  if  it  is  present.  " 

10. 33. 1  Efficiency 

The  lack  of  a  floating  point  coprocessor  means  that  more  of  the 
system  resources  (CPU  time,  memory)  will  be  required  to  perform 
floating  point  operations  and  to  provide  support  for  intrinsic 
functions  such  as  sine  and  cosine. 

10.  33.  2  Correctness 

The  lack  of  a  standard  for  use  of  a  floating  point  coprocessor 
means  that  some  Ada  compilers  will  require  the  presence  of  a 
coprocessor  and  some  will  not.  Depending  on  the  manner  in 
which  the  floating  point  coprocessor  is  used  and  the  way  in 
which  floating  point  is  implemented  by  a  particular  compiler, 
an  application  could  provide  different  answers  for  the  result 
of  a  floating  point  operation. 
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10.34  INABILITY  TO  RECOVER  PROM  CPO  FAULTS  IN  ADA 

”CPO  fault  tolerance  is  the  built-in  capability  of  a  system  to 
provide  continued  correct  execution  in  the  presence  of  a 
limited  number  of  hardware  or  software  faults.  Highly  reliable 
systems  require  that  the  software  continue' to  operate  in  the 
presence  of  CPO  faults.  " 

"Although  this  may  seem  impossible,  careful  analysis  indicates 
that  many  faults  are  momentary  and  do  not  result  in  permanent 
interruption  of  processing  capability.  However,  it  is 
essential  that  the  program  be  able  to  recover  from  such  faults 
and  continue  execution  from  the  last  checlc  point.  Ada  does  not 
directly  support  the  ability  to  recover  from  such  CPU  faults.  " 

10.3  4.1  RelieOsility 

"Although  it  is  possible  for  an  Ada  program  to  cbeckpoint  its 
data,  due  to  the  complexity  of  program  elaboration,  it  is 
diffifcult  for  an  off-  the-shelf  runtime  to  roll  back  and 
recover  from  a  CPU  reset.  "  Thus,  the  unpredictability  of  the 
CPU  fault  recovery  process  can  significantly  reduce  the  overall 
reliability  of  the  system. 

10.  3  4.  2  Correctness 

The  ability  to  dynamically  create  objects  in  Ada  at  runtime 
(data,  tasks,  etc...)  and  the  variety  of  dynamic  objects  that 
are  created  by  Ada  during  program  operation  make  it  very 
difficult  to  perform  the  reconstruction  of  t.he  runtime 
environment  that  is  required  to  properly  (correctly)  recover 
from  a  CPU  fault  and  continue  execution  from  the  last  check 
point. 
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10.  35  IMPACT  OF  ADA  COMPILBE  VALIDATION  ISSOES 

"Validation  is  the  process  of  checking  the  conformity  of  an  Ada 
compiler  to  the  Ada  programming  language  [as  specified  in  KIL- 
STD-  1615A]  and  of  issuing  certificates  indicating  compliance 
of  those  compilers  that  have  been  successfully  tested.  It 
should  be  emphasized  that  the  intent  is  only  to  measure 
conformance  with  the  standard.  Any  validated  compiler  may 
still  have  bugs  and  poor  performance,  since  performance  is  not 
being  measured  by  the  validation  tests.  ” 

"To  obtain  a  validation  certificate,  a  compiler  implementor 
must  exercise  an  Ada  Compiler  Validation  Capability  (ACVC)  test 
suite.  The  current  level  is  Version  1.9  and  it  contains  a 
series  of  over  2500  tests  designed  to  check  a  compiler's 
conformance  to  the  DoD's  Ada  language  standard,  ANSI  MIL-STD- 
1815A-1983.  " 

"yith  the  initial  validation  phase  completed  for  most 
compilers,  the  compiler  implementors  are  [finally]  shifting 
their  emphasis  to  concentrate  on  improving  the  efficiency  of 
the  generated  code  (code  optimization)  and  providing  more  user 
configurability  of  the  runtime  environment.  ” 

10.35.1  Efficiency 

The  efficiency  of  the  code  generated  by  the  current  Ada 
compilers  has  not  been  very  good  because  the  emphasis  has  been 
on  passing  the  ACVC  tests  to  achieve  validation  and  not  on 
achieving  the  performance  levels  to  support  the  development  of 
real-time  embedded  systems. 

10. 35. 2  Portability 

As  the  compiler  vendors  shift  their  emphasis  to  improvement  of 
compiler  performance,  it  expected  that  one  approach  will  be  to 
address  more  of  the  machine  dependencies  and  implementation 
details.  However,  taking  advantage  of  these  machine 
dependencies  and  implementation  details  will  reduce  the 
portability  of  the  code  produced  by  the  Ada  compilers. 

10.  35.  3  Stability 

The  compiler  validation  process  can  affect  project  stability. 
One  issue  has  "appeared  involving  what  constitutes 
""maintenance””  of  a  compiler  and  bow  much  of  it  [the  compiler] 
can  undergo  change  and  still  retain  validation  status. 

"Also,  since  Ada  validation  status  is  only  retained  for  one 
year  after  validation,  concerns  have  been  expressed  for 
programs  that  do  not  want  to  change  the  version  of  their 
compiler  after  they  begin  testing.  New  policies  have  been 
developed  to  support  baselining  a  compiler  with  respect  to  a 
project,  and  deriving  validation  status  for  similarly 
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configured  machines. 
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10.  36  INABILITY  TO  PERFORM  ASYNCHRONOOS  TASK 

"The  Ada  rendezvous  model  uses  a  synchronous  mechanism  to 
communicate  between  tasks.  Many  applications  require  that  a 
signaling  task  not  be  delayed  until  the  signaled  task  is  ready 
to  accept  the  signal.  The  mechanism  used  to  communicate 
between  tasks  in  the  Ada  rendezvous  model  is  that  both  tasks 
must  be  synchronized  together  before  any  data  or  control 
information  can  be  transferred.  ” 

"The  Ada  solution  to  this  issue  is  to  place  an  intermediate 
task  between  the  signaling  task  and  the  waiting  task.  This 
intermediate  task  would  always  be  ready  for  a  rendezvous  and 
would  effectively  buffer  the  transaction  to  provide 
asynchronous  communications.  The  impact  is  to  create  an 
additional  (logical)  context  switch." 

10.  36.  1  Efficiency 

The  'overall  system  efficiency  is  reduced  due  to  time  wasted 
because  a  signaling  task  is  delayed  until  the  signaled  task  is 
ready  to  accept  the  signal. 

If  asynchronous  task  communications  are  implemented  through  the 
use  of  an  intermediate  task,  the  additional  context  switch  that 
is  required  (due  to  the  inclusion  of  the  intermediate  task)  can 
significantly  increase  the  overhead  associated  with  this 
activity. 

10.  36.  2  Coiq>lexity 

Any  optimization  that  is  required  to  compensate  for  the 
possibly  extensive  waiting  time  for  a  signaled  task  to  accept 
the  signal  could  increase  the  overall  complexity  of  the  system. 
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10.  37  LACK  OF  IMPLEMENTATION  OP  THE  IMPLEMENTATION 

"Many  of  the  features  in  Chapter  13  [of  the  Ada  Reference 
Manual]  are  not  implemented  in  current  commercially  available 
compilers  today.  Chapter  13  of  the  Reference  Manual  for  the 
Ada  Programming  Language  is  titled,  ""Representation  Clauses 
and  Implementation-  Dependent  Features"".  These  features  are 
optional  and  therefore  a  compiler  can  have  the  status  of 
""validated""  without  any  of  these  features  implemented. 
However,  many  people  feel  that  Chapter  13  is  requited  for-  real¬ 
time  embedded  applications.  " 

The  features  addressed  in  Chapter  13  of  the  Ada  Reference 
Manual  allow  an  Ada  application  developer  to  perform  systems 
programming  tasks  by  providing  a  physical  representation  of  the 
underlying  machine.  These  features  include; 

*  Representation  Clauses 

.  *  Length  Clauses 

*  Enumeration  Representation  Clauses 
"  Record  Representation  Clauses 

*  Address  Clauses 

*  Address  Clauses  For  Interrupts 

*  Change  Of  Representation 

*  The  Package  SYSTEM 

*  System-Dependent  Named  Numbers 

I 

*  Representation  Attributes 

*  Representation  Attributes  Of  Real  IVP®s 

*  Machine  Code  Insertions 

*  Interface  To  Other  Languages 


10.  37.  1  Complexity 

The  use  of  an  Ada  compiler  without  the  Chapter  13  features 
implemented  increases  the  complexity  of  the  Ada  application 
because  the  developer  must  build  these  interfaces  to  the 
underlying  machine.  These  interfaces  must  also  be  built  to 
operate  i.n  conjunction  with  the  runtime  environment. 
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10. 37. 2  Non-Ada  Software 

The  requirement  for  the  Ada  applications  developers  to  build 
interfaces  to  the  underlying  machine  causes  them  to  use  a 
higher  amount  of  non-Ada  software. 

Maintainability  -The  additional  use  of  non-Ada  software  and  the 
required  interfaces  to  the  runtime  environment  tend  to  decrease 
the  overall  maintainability  of  the  system. 
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